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FOREWORD 


The  increasing  use  of  computers  by  Government  and  private  organiza- 
tions for  the  storage  and  manipulation  of  records  of  all  kinds — personal 
as  well  as  of  a  business  nature — has  placed  computers  and  the  systems  in 
which  they  reside  in  an  extremely  sensitive  position  in  our  society.  The 
needs  of  the  individual  as  well  as  Government  and  private  organizations 
require  that  this  data  and  their  resident  systems  be  accurate  and  reli- 
able.    These  needs  also  require  that  this  data  and  these  systems  be 
given  adequate  protection  from  threats  and  hazards.  The  establishment  of 
secure  computer  systems  is  the  way  in  which  the  computer  community  as- 
sures the  users  of  such  systems  that  all  of  these  requirements  are  being 
met . 

The  auditing  and  evaluating  of  computer  systems  for  adequate  secu- 
rity has  been  a  natural  outgrowth  of  this  widening  interest  in  this 
area.     Controls  that  provide  computer  security  are  of  interest  to  both 
the  financial  and  internal  auditors  and  has  been  made  a  subject  of  spe- 
cial consideration  by  organizations  such  as  the  Institute  of  Internal 
Auditors,  the  American  Institute  of  Certified  Public  Accountants,  and 
the  EDP  Auditors  Associtation. 

The  National  Bureau  of  Standards,  with  the  support  of  the  U.S.  Gen- 
eral Accounting  Office,  sponsored  an  invitational  workshop  in  March  of 
1977  to  explore  the  subject  of  "Audit  and  Evaluation  of  Computer  Securi- 
ty." Leading  experts  in  the  audit  and  computer  communities  were  invited 
to  share  their  thoughts  and  develop  a  consensus  view  on  ten  aspects  of 
the  subject.  These  Proceedings  are  the  results  of  that  meeting. 

To  all  those  concerned  with  the  audit  and  evaluation  of  computer 
security  today,  we  at  the  National  Bureau  of  Standards  offer  this  series 
of  consensus  reports  for  your  consideration.  The  views  expressed  do  not 
necessarily  reflect  those  of  the  National  Bureau  of  Standards,  the  U.  S. 
General  Accounting  Office,  or  any  of  the  organizations  that  sponsored  an 
individual  at  the  workshop.  However,  these  reports  do  reflect  the  compo- 
site thoughts  of  a  group  that  deserves  your  serious  attention. 


M.  Zane  Thornton 
Acting  Director 
Institute  for  Computer 
Sciences  and  Technology 
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PREFACE 


The  National  Bureau  of  Standards  (NBS)  initiated  a  Task  Group 
within  the  Federal  Information  Processing  Standards  (FIPS)  program  in 
1973  to  develop  standards  in  Computer  Systems  Security.     Task  Group  15 
(TG-15)  was  composed  of  representatives  from  private  industry  as  well  as 
Federal,  State  and  local  governments.     The  NBS  Invitational  Workshop  on 
Audit  and  Evaluation  of  Computer  Security  was  organized  as  one  phase  of 
a  two-phase  project  defined  by  the  Task  Group  in  this  important  area  of 
computer  security.    These  Proceedings  are  the  result  of  phase  one.  The 
second  phase  will  be  to  adapt  this  information  to  the  needs  of  Federal 
agencies  in  the  form  of  Federal  Information  Processing  Guidelines.  This 
latter  effort  will  be  carried  out  by  a  working  group  convened  for  this 
purpose  and  will  result  in  a  FIPS  publication  by  NBS. 

The  General  Chairman  and  organizer  of  the  Workshop  was  Robert  G. 
McKenzie  of  the  U.S.     General  Accounting  Office.     As  leader  of  the  TG-15 
project  on  computer  security  auditing,  he  initiated  and  planned  the 
Workshop  and  co-edited  these  Proceedings.    Mr.  McKenzie  is  an  audit 
manager  at  GAG  and  has  conducted  a  number  of  reviews  of  computer  securi- 
ty of  proposed  and  on-going  systems  in  the  Federal  Government. 

The  General  Vice-Chairman  of  the  Workshop  was  Zella  G.  Ruthberg  of 
the  National  Bureau  of  Standards.     As  NBS  coordinator  of  the  TG-15  secu- 
rity audit  project,  Mrs.  Ruthberg  worked  closely  with  Mr.  McKenzie  on 
the  planning,  acted  as  the  Workshop  arrangements  chairman,  and  is  co- 
editor  of  these  Proceedings.    She  has  conducted  a  wide  range  of  projects 
in  computer  science  at  NBS  and  most  recently  has  become  active  in  the 
managerial  procedures  required  for  computer  security. 

Mr.  S.  Jeffery,  Chief  of  the  Systems  and  Software  Division  of  the 
Institute  for  Computer  Sciences  and  Technology  of  NBS,  headed  the  NBS 
staff  at  the  Workshop.    Mr.  Jeffery  has  been  active  in  the  formulation 
of  policy  concerning  the  effective  utilization  of  computers  within  the 
Federal  Government  and  is  manager  of  the  computer  program  at  NBS.  This 
program  provided  the  needed  technical  and  administrative  support  for 
this  Workshop. 

I  would  like  to  thank  all  of  the  particitpants  in  this  Workshop, 
the  Chairmen  and  Recorders  of  the  sessions,  and  the  three  individuals 
named  above  for  the  success  of  the  Workshop.     The  products  to  be  derived 
from  the  Workshop  and  subsequent  efforts  in  this  area  will  have  far- 
reaching,  beneficial  effects  on  the  use  of  computers  throughout  the 
country . 

Dennis  K.  Brans tad 
Chairman,  TG-15 
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ABSTRACT 


The  National  Bureau  of  Standards,  with  the  support  of  the  U.S.  Gen- 
eral Accounting  Office,  sponsored  an  invitational  workshop  on  "Audit  and 
Evaluation  of  Computer  Security,"  held  in  Miami  Beach,  Florida  on  March 
22-24,   1977.     Its  purpose  was  to  explore  the  state-of-the-art  in  this 
area  and  define  appropriate  subjects  for  future  research.     Leading  ex- 
perts in  the  audit  and  computer  communities  were  invited  to  discuss  the 
subject  in  one  of  ten  sessions,  each  of  which  considered  a  different  as- 
pect.    A  consensus  report  was  produced  by  each  of  the  ten  sessions  and 
these  reports  form  the  body  of  these  Proceedings.    The  ten  topics  re- 
ported on  are:  Internal  Audit  Standards,  Qualifications  and  Training, 
Security  Administration,  Audit  Considerations  in  Various  System  Environ- 
ments, Administrative  and  Physical  Controls,  Program  Integrity,  Data  In- 
tegrity, Communications,  Post-Processing  Audit  Tools  and  Techniques,  and 
Interactive  Audit  Tools  and  Techniques. 


KEYWORDS:    Audit  standards,  audit  techniques,  audit  tools,  audit 
training,  communications  security,  computer  controls,  computer 
security,  data  integrity,  interactive  audit,  internal  audit,  post- 
processing audit,  program  integrity. 
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EXECUTIVE  SUMMARY 


On  March  22-24,  1977  an  Invitational  Workshop  on  Audit  and  Evalua- 
tion of  Computer  Security  was  held  by  the  National  Bureau  of  Standards 
(NBS)  in  Miami  Beach,  Florida.     The  Workshop  was  planned  and  carried  out 
by  NBS  with  the  support  of  the  U.S.  General  Accounting  Office  (GAO). 
This  Workshop  is  the  first  part  of  a  two  phase  effort,  originating 
within  Task  Group  15  (TG-15)  of  the  Federal  Information  Processing  Stan- 
dards (FIPS)  Program,  in  the  Computer  Security  Audit  area.     The  goals  of 
the  Workshop  were  to  consolidate  the  state-of-the-art  information  avail- 
able in  the  field  and  to  define  areas  for  future  research.     The  goal  of 
the  second  phase  of  this  effort  will  be  to  adapt  this  information  to  the 
needs  of  Federal  agencies  in  the  form  of  Federal  Information  Processing 
Guidelines.  It  is  expected  that  this  latter  task  will  be  carried  out  by 
a  working  group  convened  for  this  purpose. 

Under  the  direction  of  Robert  G.  McKenzie  of  the  U.S.  General  Ac- 
counting Office  and  with  Zella  G.  Ruthberg  as  the  National  Bureau  of 
Standards  liaison,  an  informal  task  team  within  TG-15  planned  the 
Workshop  format  and  subject  matter.     The  result  was  a  relatively  small 
invitational  topic  area  workshop  to  cover  ten  non-mutually  exclusive  ma- 
jor areas  of  concern  in  computer  security  audit. 

With  inputs  from  the  task  team  as  well  as  the  Institute  of  Internal 
Auditors,  the  American  Institute  of  Certified  Public  Accountants,  and 
the  Canadian  Institute  of  Chartered  Accountants,  an  outstanding  group  of 
session  Chairmen,  Recorders,  and  attendees  drawn  from  the  audit  and  com- 
puter communities  was  selected.     The  three  days  at  the  Workshop  allowed 
these  people  to  develop  the  basis  for  the  ten  reports  contained  in  these 
Proceedings.    The  following  material  summarizes  these  ten  reports.  The 
reports  are  independent  of  one  another  and  may  be  read  in  any  order. 
Note  that  the  reports  toward  the  beginning  of  the  Proceedings  are  more 
management  oriented  and  the  later  ones  more  technically  oriented. 


SESSION  ON  INTERNAL  AUDIT  STANDARDS 

In  response  to  their  charge  to  develop  a  proposed  statement  of  au- 
dit standards  for  computer  security  ,  this  group  first  defines  the 
larger  subject  of  internal  audit  of  a  computer  system,  and  then  defines 
computer  security  audit.     It  characterizes  this  audit  as  covering  ac- 
countability, primarily  in  the  areas  of  compliance  and  program  results. 
It  concludes  that  the  GAO  pamphlet  entitled  "Standards  for  Audit  of 
Governmental  Organizations,  Programs,  Activities  and  Functions"  forms  a 
sound  foundation  for  internal  audit  standards  for  EDP  audit  and  that  all 
that  is  needed  are  supplemental  standards  such  as  AICPA's  SAS3  to  define 
additional  tasks  that  the  auditor  must  perform  in  a  computer  security 
audit  to  meet  these  basic  standards.     Three  areas  are  identified  for 
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these  supplemental  standards: 

1.  Systems  Development, 

2.  Operational  Systems  (Applications  Controls), 
and 

3.  Physical  Security  and  General  Controls. 

In  the  area  of  Systems  Development,  audit  involvement  would  assure 
that  plans  are  made  for  controls  against  theft  and  error,  appropriate 
audit  trails,  conformity  with  management  objectives  and  with  the  law, 
sufficient  documentation,  appropriate  design  approval  mechanisms,  and 
general  efficiency  and  economy.     In  the  area  of  Operational  Systems,  au 
dit  would  check  that  the  application  conforms  to  standards  and  the  la- 
test design  specifications,  and  that  the  internal  controls  and  reliabil 
ity  of  data  are  sound.     In  the  Physical  Security  and  General  Controls 
area,  audit  would  verify  that  the  organization  structure,  the  physical 
facilities,  the  personnel  management,  the  back-up  capability,  and  the 
software/hardware  controls  all  help  meet  management's  objectives. 

The  recommendations  for  action  by  this  session  were: 

1.  that  GAO  review  these  supplementary  standards  and  consider 
adding  them  to  their  other  standards; 

2.  that  these  supplementary  standards  be  reviewed  and  endorsed 
by  the  Federal  Audit  Executive  Council; 

and 

3.  that  NBS  consider  these  supplemental  standards  for  inclusion 
in  a  FIPS  guideline  in  the  area  of  audit  for  computer  security. 


SESSION  ON  QUALIFICATIONS  AND  TRAINING 

In  response  to  the  question,  "What  are  the  qualifications  and 
training  necessary  to  conduct  audit  of  computer  security?,"  this  group 
draws  up  an  outline  of  the  broad  body  of  knowledge  needed  to  perform  a 
computer  security  audit.     Some  of  the  considerations  that  shape  their 
reply  are  that 

1)  computer  security  involves  all  controls  needed  to  ensure  the  in 
tegrity,  accuracy,  and  reliability  of  the  acquisition,  processing, 
storing,  and  dissemination  of  information; 

2)  persons  performing  this  audit  should  have  an  initial  degree  in 
(but  not  limited  to)  such  disciplines  as  accounting,  business  ad- 
ministration, engineering,  operations  research,  computer  science, 
or  economics  plus  a  solid  supplementary  foundation  in  management, 
auditing,  data  processing,  and/or  telecommunications; 

3)  audit  of  more  complex  systems  require  so  many  of  these  discip- 
lines that  an  interdisciplinary  team  should  probably  be  used; 

4)  training  is  available  or  can  be  installed  in  all  the  standard 
educational  channels; 

5)  costs  cannot  be  estimated  because  there  are  too  many  variables 
in  going  from  one  organization  to  the  next; 

and 
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6)  there  are  at  least  three  levels  of  knowledge  needed  for  the 
work : 

a)  general  management  and  auditing  concepts, 

b)  data  processing  and  telecommunications  expertise, 
and 

c)  a  comprehensive  integration  of  the  first  two  obtained 
through  further  training  and  experience. 

The  broad  categories  in  the  outline  of  the  common  body  of  knowledge  are: 

1.  Computer  systems,  operations,  and  software; 

2.  Data  processing  techniques; 

3.  Management  of  the  data  processing  function; 

4.  Security  of  the  data  processing  function; 

5.  Risk  analysis  and  threat  assessment; 

6.  Management  concepts  and  practices; 

7.  Auditing  concepts  and  practices; 

8.  Additional  qualifications  needed  to  evaluate  computer  security. 
A  brief  discussion  of  each  of  these  categories  is  given.     The  final  out- 
line contains  a  listing  of  the  major  disciplines  appropriate  for  each 
category. 

SESSION  ON  SECURITY  ADMINISTRATION 

This  session  responded  to  the  question,  "What  audit  approaches  and 
techniques  can  be  used  in  an  evaluation  of  the  security  administration 
function?"    Initially  this  group  discusses  the  legal  basis  for  estab- 
lishing a  Security  Administration  Function  in  a  Federal 
organization—the  Brooks  Act  (PL-89-306)  and  the  Privacy  Act  of  1974. 
It  also  proposes  that  the  Security  Administration  Function  must  be  de- 
fined in  detail  so  that  audit  of  that  function  becomes  a  standard  com- 
pliance type  review.     The  bulk  of  the  rest  of  the  paper  is  devoted  to 
defining  the  Security  Administration  Function. 

An  important  related  issue,  mentioned  in  the  early  part  of  the  pa- 
per concerns  the  need  for  international  privacy  law  compatibility. 
Privacy  legislation  has  already  been  passed  in  Sweden  and  Germany  and  is 
pending  in  Norway,  Denmark,  and  France.     International  organizations 
will  be  finding  this  an  important  issue  in  the  years  to  come.     The  re- 
port has  an  Appendix  outlining  the  German  privacy  law. 

Some  of  the  important  points  made  about  the  Security  Administration 
Function  are  that 

1.  Responsibility  for  safeguarding  an  organization's  data  and  in- 
formation resources  belongs  to  those  individuals  having  physical 
custody  and  accountability  for  it,  i.e.  all  levels  of  line  manage- 
ment . 

2.  The  Security  Administration  Program  is  a  staff  function  and 
should  consist  of  developing  overall  policy  and  monitoring  overall 
ef f ectiveness . 

3.  Planning  for  security  administration  should  be  carried  out  at 
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three  management  levels: 

a)  broad  policy  level  using  top  management  input, 

b)  an  intermediate  policy  level  developing  implementation  in- 
structions , 

c)  the  implementation  level  developing  schedules  and  resource 
requirements. 

4.  Management  controls  to  ensure  that  security  objectives  are 
achieved  fit  into  three  categories —  policies  that  are  formulated 
at  the  top,  procedures  for  administrative,  physical,  and  technical 
security  measures,  and  practices  for  the  standard  management  ac- 
tivities . 

5.  ADP  security  controls  should  include  a)  administrative  safe- 
guards in  the  form  of  contingency  plans,  security  documentation, 
authorization  control  lists,  program  access  controls,  personnel 
rules;  b)  physical  security  safeguards  such  as  area  restrictions, 
disaster  back-up,  storage  libraries,  disposal  procedures;  and  c) 
technical  security  in  the  form  of  a  security  system  to  handle  data 
and  files,  program  libraries,  operating  system(s),  teleprocessing, 
and  encryption. 

6.  Training  is  needed  for  systems  people  as  well  as  users. 

An  example  of  a  suggested  security  system  for  an  on-line  system  is  then 
given . 

The  final  requirements  of  the  group  are  that  the  Audit  and  Security 
Administration  functions  should  be  independent  of  one  another  and  that 
the  Audit  function  reports  to  the  agency  head.     Given  this  set  of  condi- 
tions and  the  clear  definition  of  the  Security  Administration  function, 
the  audit  of  this  function  is  then  a  compliance  review. 


SESSION  ON  AUDIT  CONSIDERATIONS  IN  VARIOUS  SYSTEM  ENVIRONMENTS 

The  question  this  session  considered  was,  "What  are  the  considera- 
tions to  be  given  to  the  audit  of  computer  security  in  various  system 
environments?"  This  group  identifies  four  conceptual  modules  for  the 
development  of  an  open-ended  structured  model  of  computer  security  au- 
dit.    These  are: 

1.  Defining  three  vital  audit  components — access  control,  accuracy, 
and  availability. 

2.  Describing  a  morphology  of  systems  and  environments:  Physical 
components,  systems  structure,  and  people.     The  systems  are 
described  by  five  identifiable  characteristics  — number  of  users, 
types  of  service,  system  organization,  user  access,  and  application 
mix. 

3.  Defining  a  methodology —  a  computer  audit  model —  which  estab- 
lishes a  scorecard  value  for  each  parameter  capable  of  being  audit- 
ed . 

4.  Performing  a  model  validation  by  testing  the  model  with  four  ex- 
amples . 
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This  group  declares  that  an  auditor  goes  through  a  set  of  steps 
parallel  to  those  executed  by  a  design  team.     It  then  proceeds  to  out- 
line the  design  team  activity,  i.e.  to  define  requirements,  objectives, 
and  sensitivity;  to  specify  the  physical,  system,  and  administrative 
parameters;  to  specify  possible  control  techniques;  to  make  four  judge- 
ments concerning  each  control — 

1.  cost, 

2.  effectiveness  in  maintaining  access  control, 

3.  effectiveness  in  maintaining  accuracy, 

4.  effectiveness  in  maintaining  availability, 

giving  each  of  the  three  effectiveness  aspects  of  the  control  a  theoret- 
ical score  of  1  to  10  and  using  all  four  to  make  decisions  on  whether  or 
not  to  use  the  control.     The  next  design  team  activities  then  are  to 
select  a  subset  of  these  controls  to  provide  the  desired  level  of  pro- 
tection; to  incorporate  these  controls  into  the  environment,  to  reassess 
the  system,  and  to  iterate  until  all  requirements  are  satisfied.  The 
parallel  operations  performed  by  an  auditor  would  be:     to  review  the  ob- 
jectives, requirements,  and  sensitivity;     to  determine  the  actual  en- 
vironment; to  identify  the  control  techniques  being  used;     to  perform  a 
cost  and  effectiveness  analysis,  this  time  using  hardware  and  software 
techniques  to  give  each  control  its  composite  score;     and  to  prepare  a 
report  on  the  findings.     The  group  developed  a  tabulation  sheet  for 
recording  these  findings  for  any  particular  system.     The  paper  has  four 
system  examples  on  the  tabulation  sheets  to  illustrate  this  approach  to 
computer  security.     It  also  points  out  that  there  are  currently  no  stan- 
dard methods  for  evaluating  a  control,  i.e.  giving  it  a  score  of  1  to 
10.     This  is  the  area  that  needs  a  considerable  amount  of  future  effort. 


SESSION  ON  ADMINISTRATIVE  AND  PHYSICAL  CONTROLS 


This  group  responded  to  the  question,  "What  are  the  audit  ap- 
proaches and  techniques  for  evaluation  of  administrative  and  physical 
controls  in  an  ADP  environment,  including  contingency  planning,  etc.?" 
The  group  initially  establishes  the  thesis  that  the  concerns  of  data 
security  and  the  responsibilities  of  the  auditor  are  complementary  since 
both  deal  with  the  protection  of  resources  within  the  data  processing 
mission.  The  areas  of  concern  to  the  auditor  all  have  problems  associat- 
ed with  them.    Some  of  the  more  important  areas  mentioned  are 

1 .  the  need  for  a  workable  definition  of  security 

2.  the  need  for  an  explicit  statement  of  security  policy 

3.  the  need  for  accepted  standards  of  good  practice 

4.  the  need  to  know  what  tests  and  examinations  are  appropriate 

5.  the  need  to  know  the  hazards  that  a  system  is  subject  to. 
The  remainder  of  the  report  covers  suggestions  for  the  auditor. 

First,  four  general  areas  of  interest  to  the  auditor  are  discussed 
and  then  five  non-mutually  exclusive  audit  approaches  to  data  processing 
security  are  discussed  in  detail.     The  four  general  areas  are 

1.  Audit  focus  and  materiality — Security  protective  measures  should 
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yield  "an  acceptable  level  of  risk."    The  auditor  should  review 
that  this  is  the  case,  particularly  for  the  most  sensitive  applica- 
tions. 

2.  Standards  of  practice  and  their  documentation — Five  references 
are  briefly  discussed  for  their  contributions  in  this  area.  The 
best  single  one  is  stated  to  be  "Computer  Control  Guidelines"  and 
"Computer  Audit  Guidelines"  by  the  Canadian  Institute  of  Chartered 
Accountants. 

3.  Security  audit  report — An  outline  of  a  security  audit  report  is 
given  in  two  parts-  one  part  addressed  to  higher  management  and  the 
second  to  the  auditee  and  his  management. 

4.  Best  traditional  audit  techniques — These  are: 

Selective  protection — review  key  resource  protection, 
Test — use  actual  tests  where  possible, 
Interview — with  all  involved  employees  and  management, 
Technical  cooperatives  (co-op) — use  talent  from  other 
organizations  and  locations. 

The  five  audit  approaches  are  each  discussed  under  the  headings  Concern, 

Purpose,  Approach,  and  Scope.     They  are: 

1 .  System  Development  and  Maintenance  Practices  Audit 

2.  Application  Review 

3.  Installation  Security  Review 

U.  Security  Function  (Data  Base/Communication  Environ- 
ment) Review 

5.  Compromise  Attempt. 

The  report  concludes  that  the  issues  for  the  DP  community  lie  in 
adapting  to  the  new  technologies  (increasing  portability  of  storage 
media,  mass  storage,  and  distributed  systems),  satisfying  the  need  for  a 
single  compendium  of  audit  concerns  and  techniques,  and  improvement  and 
change  by.  management  in  programming  application  development  and  system 
development . 

SESSION  ON  PROGRAM  INTEGRITY 

This  session  responded  to  the  question  "What  are  the  audit  ap- 
proaches and  techniques  for  evaluation  of  program  integrity  in  an  ADP 
environment?"  It  emphasizes  that  program  integrity  must  be  considered 
over  the  entire  life  cycle  of  the  program.     Program  integrity  concerns: 
1)  correctness  in  fulfilling  requirements  and  doing  nothing  else;  2)  sa- 
tisfaction of  trained  user  expectations;  3)  usefulness  in  fulfilling  an 
intended  mission;  and  4)  the  ability  to  be  evaluated  so  that  a  level  of 
trust  in  the  program  can  be  established. 

Program  integrity  assessment  is  a  multi-dimension  problem.  Determining 
when  in  the  life  cycle  to  audit  is  one  dimension.     Other  dimensions  in- 
clude the  severity  of  the  security  threat  and  the  methods  employed  dur- 
ing development  to  achieve  integrity. 
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The  methods  for  achieving  program  integrity  can  be  put  into  three 
categories : 

1.  those  that  give  evidence  the  program  is  correct, 

2.  those  that  show  it  is  robust  and  will  perform  adequately  in  the 
face  of  unexpected  events, 

3.  those  that  show  it  is  trustworthy  and  developed  in  accord  with 
good  practice. 

A  discussion  of  methods  in  each  of  these  categories  is  included  in  the 
paper. 

The  recommendations  from  the  group  are: 
For  existing  sotware: 

1.  Be  cautious  in  assuming  program  integrity  exists. 

2.  Use  the  limited  existing  tools,  guided  by  a  careful  risk 
management  analysis. 

3.  Improve  physical  and  administrative  controls  and  thus  reduce 
the  effect  of  lack  of  program  integrity. 

4.  Reduce  the  exploiter  population  by  access  controls. 

5.  Reduce  asset  exposure  by  removing  assets  from  the  system  when 
they  are  not  in  use. 

For  future  software: 

1.  Improve  the  program  production  process. 

2.  Assure  program  integrity  compliance  through  the  entire  life  cy- 
cle. 

For  organizations: 

1.  Perform  a  self-assessment  of  its  threats  and  its  involvement  in 
the  life  cycle  of  the  programs  it  uses. 

2.  Create  guidelines  for  the  development  and  acquisition  of 
software  that  is  auditable  for  program  integrity. 


SESSION  ON  DATA  INTEGRITY 

The  question  addressed  by  this  group  was,  "What  are  the  audit  ap- 
proaches and  techniques  for  evaluation  of  the  data  integrity  in  an  ADP 
environment?"    The  group  decided  to  limit  itself  to  considerations  of 
those  safeguards  having  a  direct  bearing  on  data  integrity  audit,  assum- 
ing that  physical,  operational,  administrative,  and  software 
measures — all  necessary  for  data  integrity — would  be  handled  by  other 
sessions.     This  group  defined  data  integrity  as  the  state  that  exists 
when  data  is  (within  defined  limits  of  reliability)  accurate,  con- 
sistent, authorized,  valid,  complete,  unambiguaous ,  and  processed  ac- 
cording to  specifications  in  a  timely  manner.     The  objectives  of  a  data 
integrity  audit  are  evaluation  of  compliance  with  and  adequacy  of  exist- 
ing policies  and  procedures,  and  recommendations  of  corrective  actions. 
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To  achieve  this  objective,  one  needs  to  evaluate  the  following 
areas : 

o  reliability  of  the  data  source 

o  source  data  preparation 

o  data  entry  controls 

o  data  input  acceptance  controls 

o  data  validation  and  error  correction 

o  processing  specifications 

o  output  and  distribution  controls 

and 

o  auditability . 

The  group  then  outlined  activities  for  producing  a  comprehensive 
audit  work  plan,  and  briefly  discussed  a  variety  of  methods  for  data  in- 
tegrity auditing.     Some  of  those  included  are: 

o  checks  with  users  on  accuracy,  completeness,  and  consistency; 

o  possible  sampling  techniques; 

o  parallel  processing; 

o  integrated  test  facility  (ITF); 

o  System  Control  Test  Review  File  (SCARF); 

o  tracing  tagged  transactions; 

o  test  decks; 

o  questionnaires; 

o  procedural  walk-throughs ; 

o  activity  logs. 


SESSION  ON  COMMUNICATIONS 

This  group  responded  to  the  question,  "What  are  the  audit  ap- 
proaches and  techniques  for  evaluation  of  communications  in  an  ADP  en- 
vironment?"   They  limit  their  discussion  to  guidelines  for  a  data  com- 
munication security  audit  of  a  computer  system  that  uses  a  data  communi- 
cation network.     This  audit  applies  to  the  hardware,  software,  and  peo- 
ple involved  with  the  data  communications  of  the  computer  system.  The 
group  recommends  that  such  an  audit  should  be  made  on  sensitive  applica- 
tions and  the  general  data  communications  system,  with  the  frequency  be- 
ing directly  related  to  the  sensitivity  of  the  applications  or  system. 
The  general  approach  for  this  type  of  audit  should  be  a  transaction  flow 
analysis,  tracking  transactions  both  from  the  input  terminal  through  the 
network  to  the  computer,  and  in  the  reverse  direction  (computer  to  ter- 
minal ) . 

A  specific  tool  developed  by  the  group  for  conducting  this  type  au- 
dit is  a  resource/exposure/safeguard  matrix.     This  matrix  contains  a 
list  of  ten  system  resources  down  the  left  hand  side,  a  list  of  six  ca- 
tegories of  exposure  across  the  top  and  an  enumeration  of  appropriate 
safeguards  that  might  be  in  place  for  each  combination  of  resources  and 
exposures.     The  auditor's  job  would  then  be  to  determine  what  are  the 
actual  resources  of  the  computer  system  (terminals,  distributed 


xxvi 


intelligence,  modems,  local  loops,  lines, 

multiplexors/concentrators/switches,  front-end  processor,  computer, 
software,  and  people);  and  to  see  what  safeguards  are  in  place  to  pro- 
tect these  resources  against  the  possible  exposures  (errors  and  omis- 
sions, disaster  and  disruptions,  loss  of  integrity,  disclosure,  defalca- 
tion, and  theft  of  resources).     Each  of  the  seventeen  safeguards  in  the 
report  (as  well  as  the  resources  and  exposures)  are  defined.     In  addi- 
tion, for  each  safeguard  there  is  a  statement  about  what  the  auditor 
should  do  with  respect  to  his  review  of  this  safeguard. 

The  paper  points  out  its  own  limitations — that  the  safeguards  are 
not  all-inclusive,  will  only  assist  in  achieving  security  but  not 
guarantee  it,  may  not  apply  to  all  applications,  and  only  reflect  the 
current  state-of-the-art  methods. 


SESSION  ON  POST-PROCESSING  AUDIT  TOOLS  AND  TECHNIQUES 

The  question  this  group  addressed  was,  "What  are  the  post- 
processing audit  tools  and  techniques  available  or  needed  for  the  effec- 
tive use  of  the  various  system  journals  and  logs  in  an  audit  of  computer 
security?"  They  initially  describe  the  general  objectives  of  such  an  au- 
dit as  determining  the  existence,  scope,  and  adequacy  of  controls  in  the 
light  of  level  of  protection  required.  They  note  the  specific  objectives 
as  establishing  the  existence  of  uniqueness  of  transactions,  transaction 
integrity  (completeness,  accuracy,  and  authorization  controls),  process- 
ing integrity,  distribution  controls,  recoverability  controls,  and  vio- 
lation controls.     The  terms  "computer  security",  "computer  security  au- 
dit", "post-processing  audit",  "logs",  "tools  vs.  techniques",  and 
"transaction"  are  defined  to  enhance  the  clarity  of  the  document. 

This  group  then  describes  what  it  considers  to  be  the  essence  of  a 
post-processing  security  audit.     Such  an  audit  is  always  concerned  with 
o  INPUT 
o  PROCESS 
o  OUTPUT 
and 

o  ACCESS  to  any  of  the  above  three. 

The  objectives  of  a  security  audit  can  be  achieved  by  looking  for 
information  detailed  in  a  log  on  any  of  the  above  components.     This  log 
would  show  five  basic  types  of  information: 

1.  WHO — identifies  initiator  of  an  action, 

2.  FUNCTION — describes  the  processing  activity, 

3.  WHAT — identifies  objects  of  processing  activity, 

4.  STATUS — refers  to  FUNCTION  and  associated  initiator  and  affected 
objects , 

5.  TIME — gives  it  a  date-time  stamp. 

An  example  is  given  of  the  security  information  requirements  for  an  EFTS 
system. 
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Post-processing  techniques  are  then  described  under  the  basic  four 
components  of  an  audit.     For  Access  and  input  one  would  use  logs  of 
successes,  logs  of  failures,  and  a  log  continuity  check.     For  Process 
there  are  manual  checking,  control  totals,   test  data,  integrated  test 
facility,  tagging,  extended  record  maintenance,  tracing,  mapping,  recom- 
pilation,  parallel  simulation,  and  retrieval  programs.     For  Output  there 
are  output  listings  of  dispositions  and  authorization  listings. 

The  conclusions  and  recommendations  of  the  group  were: 

1.  Existing  software  tools  offer  much  but  could  be  made  easier  to 
use  by 

a)  publishing  a  catalog  of  these  tools  for  the  auditor. 

b)  creating  facilities  to  easily  combine  the  use  of  two  of 
these  tools. 

2.  Needed  techniques  are 

a)  a  method  for  maintaining  the  security  of  the  security  log. 
(Some  possibilities  are  using  present  operating  systems,  or 
using  a  special  tamper  proof  recording  device  to  record  all 
activity,  or  a  complete  hardware  monitor  similar  to  a  cockpit 
flight  recorder). 

b)  higher  level  software  to  access  and  manipulate  logs. 

SESSION  ON  INTERACTIVE  AUDIT  TOOLS  AND  TECHNIQUES 

This  group  responded  to  the  question,  "What  are  the  interactive  au- 
dit tools  and  techniques  available  or  needed  to  permit  on-line  auditing 
of  computer  security?"  This  session  explored  a  subject  area  which  is  in 
the  very  early  stages  of  development.  The  group  defines  its  overall  goal 
as  "The  development  of  an  auditing  approach  for  the  use  of  on-line  or 
interactive  techniques  to  achieve  performance  assurance  in  computer  sys- 
tems." and  its  specific  objectives  as 

1.  Define  the  scope  and  requirements  for  interactive  tools  and 
techniques. 

2.  Review  and  define  auditability  and  control  characteristics  in 
computer  systems. 

3.  Describe  tools  and  techniques  available  and  specify  needed  ones. 

4.  Develop  criteria  for  the  use  of  these  tools  in  specific  systems 
environments  and  define  the  required  interfaces  (e.g.  with  Data 
Base,  Operating  Systems). 

In  order  to  achieve  these  objectives  the  group  first  defines  a 
number  of  terms,  the  most  central  one  being  'interactive  auditing '-an 
activity  consisting  of  interactive  audit  programming  and  interactive  au- 
dit processing.     Interactive  audit  for  computer  security  is  then  put 
into  the  larger  framework  of  Performance  Assurance  (PA)  (defined  as  as- 
suring that  a  computer  system  is  performing  its  intended  functions 
within  a  specified  degree  of  accuracy,  timeliness,  and  data  security, 
and  that  it  is  not  performing  unintended  functions).     Performance  as- 
surance is  initially  described  in  terms  of  the  functions  performed  by 
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several  different  kinds  of  people,  including  the  Certified  Public  Ac- 
countant, senior  organizational  management,  internal  auditors,  the  qual- 
ity assurance  function,  and  operational  management.     However,  the  PA 
function  is  largely  discussed  in  terras  of  four  activities: 

1.  Setting  PA  objectives  relating  to 

a)  the  nature  and  purpose  of  the  testing, 

b)  the  nature  of  the  computer  system  being  tested; 

2.  Gathering  information  needed  to  review,  evaluate,  or  establish 
systems,  procedures,  and  controls; 

3.  Performing  PA  analyses  and  evaluations  suitable  for  the  nature 
and  complexity  of  the  system  application; 

4.  Designing  and  performing  PA  test  procedures  as  a  result  of  the 
analyses  and  evaluations. 

Existing  audit  tools  and  techniques  to  accomplish  the  above  PA  ac- 
tivities are  divided  into  two  classes,  batch  and  interactive,  with  ad- 
vantages and  disadvantages  of  each  being  given.    Available  batch  tools 
are  utility  programs,  test  decks,  audit  modules,  integrated  test  facili- 
ty (ITF) ,  test  data  generator,  snapshot  (with  tagging),  tracing,  SCARF, 
audit  software  packages,  and  parallel  simulation.  Interactive  tools  are 
Audit  Command  Language  (ACL)  and  National  Automated  Accounting  Research 
System  (NAARS).     The  benefits  of  interactive  tools  and  techniques  are 
discussed.     All  audit  tools  and  techniques  are  tabulated  by  PA  activi- 
ties performed. 

A  comprehensive  discussion  of  needed  tools  and  techniques  is  then 
given.  They  are  divided  into  five  broad  categories: 

1.  near  real-time  error  detection  and  correction, 

2.  monitoring  of  adequacy  of  controls, 

3.  measurement  of  design  accuracy, 

4.  program  modification  control, 
and 

5.  monitoring  system  trouble  indicators. 

This  part  of  the  report  outlines  a  large  number  of  tools  that  need 
development  in  order  to  make  interactive  auditing  a  reality.  These 
tools  and  techniques  are  also  tabulated  by  PA  activities  performed. 

The  broad  recommendations  of  this  group  are  that  further  delibera- 
tions and  research  are  required  in  the  following  areas: 

1.  Specifications  of  design  and  performance  requirements  for  in- 
teractive audit  tools  and  techniques. 

2.  Designs  of  interactive  audit  tools  and  techniques  for  interfaces 
with  operating  systems  and  data  base  management  systems. 

3.  Behavioral  audit  research  to  study  audit  behavior  in  an  interac- 
tive human-machine  mode  of  operation. 

4.  Development  of  a  comprehensive  audit  and  control  theory  to  guide 
PA  professionals  in  their  activities  and  software  designers  in  the 
development  of  appropiate  audit  tools  and  techniques. 
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PART  I:  INTRODUCTION 


1.     HOST  WELCOMING  ADDRESS 


S.  Jeffery 
National  Bureau  of  Standards 


I'd  like  to  welcome  all  of  you  to  the  National  Bureau  of  Standards' 
Invitational  Workshop  on  Audit  and  Evaluation  of  Computer  Security. 
This  will  be  a  memorable  meeting  because  of  the  qualifications  of  those 
here  today,  as  well  as  the  broad  scope  of  organizations  and  disciplines 
they  represent. 

It  is  interesting  to  note  that  33%  of  the  Workshop  attendees 
represent  nearly  a  dozen  Federal  agencies  and  organizations.  The 
Federal  agencies  include:     the  General  Accounting  Office,  the  Department 
of  Health,  Education,  and  Welfare,  the  Department  of  Defense,  the  Gen- 
eral Services  Administration,  the  Department  of  Agriculture  and,  of 
course,  our  own  Department  of  Commerce. 

Although  we  have  an  impressive  list  of  persons  from  these  various 
Government  agencies,  I  would  especially  like  to  welcome  Frank  S.  Sato, 
the  Deputy  Assistant  Secretary  of  Defense  for  Audit;  Donald  L.  Scantle- 
bury,  the  Director  of  the  Financial  and  General  Management  Studies  Divi- 
sion of  the  General  Accounting  Office;  Howard  R.  Davia,  the  Director  of 
the  Office  of  Audit  at  the  General  Services  Administration;  Donald  L. 
Eirich,  Associate  Director  of  the  Logistics  and  Communications  Division 
of  the  General  Accounting  Office;  and  C.  William  Getz,  Regional  Commis- 
sioner of  the  General  Services  Administration,  Region  9. 

Their  respective  experience  will  provide  an  important  addition  to 
the  rich  mixture  of  knowledge  here  today. 

The  remaining  67%  of  the  attendees  come  from  accounting  firms, 
software  and  hardware  organizations,  private  industry,  and  universities. 

We  have  a  solid  contingent  from  the  accounting  world  with  six  firms 
represented.     There  are  seven  software  houses  and  two  main- frame 
manufacturers;  in  the  university  area,  three  U.S.  universities;  and  in 
the  private  sector,  twenty-two  firms  drawn  from  such  diverse  fields  as 
banking,  utilities,  the  fuel  industry,  insurance,  research,  publishing, 
a  credit  bureau,  the  photographic  industry,  and  law  enforcement — as 
represented  by  the  Royal  Canadian  Mounted  Police. 
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A  second  cut  at  the  attendee  list  for  this  Workshop  can  be  made 
from  the  point  of  view  of  skills  and  knowledge  represented.     The  audit 
aspect  of  this  Workshop  is  covered  by  persons  from  the  American  Insti- 
tute of  Certified  Public  Accountants,  the  Institute  of  Internal  Audi- 
tors, the  EDP  Auditors  Association,  the  Association  of  Government  Ac- 
countants, six  large  accounting  firms  in  the  private  sector,  and  audi- 
tors from  various  Government  and  private  organizations. 

The  computer  aspect  of  our  Workshop  is  represented  by  persons  en- 
gaged in  developing  control  software  and  techniques  for  industry,  for 
Government,  and  for  universities  with  a  strong  contingent  of  leading- 
edge  researchers  in  all  these  areas. 

It  should  be  clear  from  all  that  I  have  said  that  we  have  an  unusu- 
al array  of  talents  assembled  for  this  workshop. 

I  think  that  this  is  the  first  time  that  such  a  breadth  and  depth 
of  abilities  has  been  focused  on  the  subject  of  audit  and  evaluation  of 
computer  security. 

I'd  like  to  thank  our  Chairman,  Mr.  Robert  G.  McKenzie  of  the  Gen- 
eral Accounting  Office  for  his  efforts  in  guiding  the  evolution  of  this 
Workshop.     He  was  instrumental  in  selecting  the  topics  for  discussion  in 
the  various  sessions  and  Session  Chairmen,  and  provided  constant  gui- 
dance in  the  selection  of  session  attendees. 

My  thanks  also  to  Mrs.  Zella  G.  Ruthberg  of  my  own  staff  who  has 
worked  with  Bob  McKenzie  throughout  the  planning.     She  has  also  been 
responsible  for  coordinating  all  arrangements  for  finding  and  obtaining 
these  fine  accommodations. 

Our  specific  interest  in  this  Workshop  is  to  accumulate  sufficient 
information  to  form  the  basis  for  Federal  Information  Processing  Stan- 
dards and  Guidelines  in  the  area  of  audit  and  evaluation  of  computer 
security . 

The  Institute  for  Computer  Sciences  and  Technology  of  the  National 
Bureau  of  Standards  has  the  responsibility  of  providing  Federal  agencies 
with  standards  and  guidelines  for  data  processing,  and  it  is  expected 
that  the  Proceedings  of  this  Workshop  will  be  the  precursor  to  such  a 
guideline. 

Considering  the  broad  spectrum  of  abilities  assembled  here,  these 
Proceedings  will  undoubtedly  be  a  valuable  document  in  itself,  to  be 
used  by  all  those  working  in  the  internal  audit  areas. 

Again,  let  me  thank  you  all  for  your  interest  in  coming,  and  I  want 
to  wish  you  every  success  in  your  efforts. 
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2.     EDITOR'S  COMMENTS  ON  THE  SESSIONS  AND  THE  REPORTS 


2.1    Some  Definitions  of  Terms 

Each  attendee  was  furnished  a  copy  of  FIPS  PUB  39,  "Glossary  for 
Computer  System  Security,"  in  an  attempt  to  maintain  uniformity  of 
technical  terms  in  the  reports  of  the  various  sessions.     A  number  of  the 
sessions  chose  to  redefine  a  few  terms  and  use  others  not  included  In 
the  Glossary.     In  most  of  these  cases,  the  definitions  as  used  by  the 
session  participants  have  been  Included  as  an  integral  part  of  their  re- 
ports.    The  following  is  a  discussion  of  a  few  terms  considered  to  be 
essential . 

Computer  security  audit .     An  independent  evaluation  to  determine 
(1)  the  accuracy  and  reliability  of  the  data  maintained  on  or  generated 
by  an  automated  data  processing  system,  (2)  the  adequacy  of  protection 
afforded  the  organization's  assets  to  include  hardware,  software,  and 
data  from  all  significant  anticipated  threats  or  hazards,  and  (3)  the 
operational  reliability  and  performance  assurance  of  the  automated  data 
processing  system. 

Internal  audit .    An  independent  appraisal  activity  within  an  organ- 
ization for  the  review  of  operations  as  a  service  to  management.  The 
overall  objective  of  internal  auditing  is  to  assist  management  in  at- 
taining its  goals  by  furnishing  information,  analyses,  appraisals,  and 
recommendations  pertinent  to  management's  duties  and  objectives.  The 
need  for  effective  internal  auditing  in  the  Federal  agencies  has  been 
recognized  by  the  Congress  in  a  number  of  laws,  particularly  the  Budget 
and  Accounting  Procedures  Act  of  1950  which  requires  the  head  of  each 
agency  to  establish  and  maintain 

"...  internal  control  designed  to  provide... 
effective  control  over  and  accountability  for  all  funds, 
property,  and  other  assets  for  which  the  agency  is 
responsible,  including  appropriate  internal  audit." 

External  audit .     Frequently  considered  synonymous  with  financial 
audits  conducted  by  certified  public  accountants.     Financial  audits  are 
objective  examinations  of  financial  statements,  accompanied  by  the  ex- 
pression of  a  competent  opinion  concerning  the  fairness  of  the  presenta- 
tion of  those  financial  statements.     However,  a  broad  definition  of 
external  audit  would  simply  be:     An  audit  of  any  type  conducted  by  indi- 
viduals independent  of  the  organization  under  review. 
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2.2  Observations 


Audit  and  evaluation  of  computer  security  is  a  very  complex  subject 
that  must  be  considered  from  a  total  system  perspective.     It  involves 
the  evaluation  of  all  of  the  controls  necessary  to  assure  computer  secu- 
rity as  defined  under  "computer  security  audit"  in  section  2.1. 

The  total  security  system  that  provides  such  assurance  consists  of 
controls  that  can  be  grouped  into  various  categories,  such  as  physical, 
procedural,  operational,  technical,  etc.    However,  it  does  little  good 
to  have  strong  controls  in  one  area  if  the  controls  in  another  are  ei- 
ther weak  and  unreliable  or  can  easily  be  circumvented.    The  end  result 
could  be  the  same  a  disaster.     In  view  of  this  and  the  known  interre- 
lationship between  various  categories  of  controls,  it  is  necessary  that 
all  controls  be  evaluated  prior  to  rendering  an  opinion  as  to  the  ade- 
quacy of  computer  security  within  any  automated  data  processing  system. 
Therefore  each  part  of  these  Proceedings  should  be  considered  with  equal 
weight  when  developing  a  program  for  such  audits. 

2.3    Reading  the  Proceedings 

The  reports  of  the  ten  sessions  are  independent  of  one  another  and 
may  be  read  in  any  order.    Note  that  the  reports  toward  the  beginning  of 
the  Proceedings  are  more  management  oriented  while  those  toward  the  end 
are  more  technically  oriented.  A  detailed  Table  of  Contents  has  been  in- 
cluded as  an  aid  to  locating  specific  materials.    Major  recommendations 
and  conclusions  of  the  sessions  can  be  found  in  the  Executive  Summary  at 
the  beginning  of  these  Proceedings.     The  account  of  why  the  Workshop  was 
held,  how  it  evolved,  and  how  the  session  reports  were  generated  can  be 
found  in  Appendix  B. 
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PART  II:    KEYNOTE  ADDRESS 


DONALD  L.  ADAMS 
American  Institute  of  Certified  Public  Accountants 


Donald  L.  Adams  is  Managing  Director  of 
Administrative  Services  at  the  American  In- 
stitute of  Certified  Public  Accountants,  with 
responsibility  for  internal  applications  of 
the  computer  as  well  as  development  of  its 
use  in  the  accounting  and  auditing  practices 
of  members.    His  administrative  responsibil- 
ities include  Personnel,  Purchasing,  Office 
Management,  Printing  and  Shipping.    Long  a 
member  of  AICPA,  he  has  served  on  a  number  of 
its  committees  in  the  computer  area,  in- 
cluding the  chairmanship  of  the  EDP  Auditing 
Committee.    He  is  a  former  member  of  the 
Computer  Committee  of  the  New  York  State 
Society  of  CPA's. 

Before  coming  to  AICPA  in  June  1973, 
Mr.  Adams  had  for  three  years  been  Assistant 
Director  of  Data  Processing  at  the  investment 
banking  firm,  Salomon  Brothers.    Prior  to  that,  he  had  been  Manager  of 
Computer  Auditing  at  Peat,  Marwick,  Mitchell  &  Co.    He  has  been  in- 
volved in  computer  auditing  since  1960,  has  written  many  articles  on 
the  subject,  and  has  lectured  extensively  in  the  United  States,  Canada 
and  Europe.    He  is  Editor  of  the  monthly  newsletter,  EDPACS  (EDP 
Audit  Control  &  Security).    He  studied  at  Massachusetts  Institute  of 
Technology  and  Syracuse  University,  earning  the  B.S.  degree  Magna  Cum 
Laude  from  the  latter  institution  in  1959. 


Biographical  Sketch 
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Keynote  Address 
Proceedings  of  the  Workshop  on  Audit 
and  Evaluation  of  Computer  Security 

Donald  L.  Adams 


1.  INTRODUCTION 


These  workshop  sessions  are  quite  valuable.     They  are  brief  and 
limited  to  a  stated  period  of  time.     This  is  a  positive  factor  in 
insuring  that  they  accomplish  their  goals.     Since  the  time  is  limited, 
there  is  a  constraint  on  the  amount  of  debating  that  can  take  place. 
This  is  bound  to  be  a  help.     In  many  other  meetings,  we  seem  to  be 
able  to  debate  topics  virtually  forever.     Having  a  limited  time 
period  means  you  have  a  better  chance  of  getting  something  done.  It 
also  means  that  you  do  not  have  time  to  conduct  a  survey.     Thank  God  I 

It  seems  that  any  time  a  committee  addresses  a  particular  problem, 
the  first  thing  they  want  to  do  is  conduct  a  survey.     They  always 
seem  to  be  searching  for  that  one  elusive  nugget  of  truth  that  might 
be  buried  out  there  somewhere  in  the  world.     Hopefully,  a  survey 
might  uncover  that  gem  of  wisdom.     However,  I  have  never  known  a  case 
where  this  happened. 

Most  of  us  went  to  school  when  the  scientific  method  was  very 
much  in  vogue.     As  a  result,  using  the  scientific  approach  to  problem 
solving  makes  us  feel  comfortable.     Unfortunately,  accounting  and 
auditing  are  not  sciences.     They  are  at  best  imperfect  art  forms. 
In  consequence  the  application  of  the  scientific  method  is  a  mistake. 
A  group,  such  as  the  one  that  is  attending  this  workshop,  is  hand 
picked  to  be  a  cross  section  of  the  most  knowledgeable  people  working 
in  the  particular  field.     It  is  a  good  bet  that  there  is  not 
a  single  important  thing  going  on  in  the  fields  of  auditing  and 
evaluating  computer  security  that  is  not  known  by  at  least  one  person 
attending  this  workshop.     That  is  where  the  true  value  of  these 
workshops  comes  into  play.     Knowledgeable  people  get  together,  pool 
their  information,  and  produce  a  document  that  will  inform  others. 
Used  properly,  this  is  a  very  cost  effective  way  of  distributing 
knowledge.     It  should  be  used  more  often. 

2.     AN  APPROACH  TO  THE  WORKSHOP 


The  outline  of  the  topics  to  be  covered  in  this  workshop  includes 
ten  basic  areas.     It  is  a  very  ambitious  program.     About  a  year  ago. 


I  was  involved  in  a  similar  effort  in  regard  to  the  Data  Base 
Directions  Workshop.     It  might  be  useful  to  review  the  approach  we  used 
in  trying  to  meet  our  workshop  objectives.     The  first  hour  was  spent 
in  brainstorming  the  major  topics  to  be  covered.     At  the  end  of  the 
hour  we  listed  the  projects  and  voted  to  select  the  five  that  were 
most  important.     A  time  budget  was  established  for  each  of  them.  If 
we  allotted  five  hours  to  a  topic,  we  discussed  it  for  five  hours  and 
then  moved  on  to  the  next  one.     The  approach  worked  quite  well  and  it 
may  prove  helpful  to  some  of  you  over  the  next  few  days . 

3.     COMMENTS  ON  PROPOSED  TOPICS 

I  would  like  to  offer  a  few  comments  about  each  of  the  session 
topics . 

3.1  Internal  Audit  Standards 

It  is  difficult  for  certified  public  accountants  to  establish 
audit  standards.     It  is  even  harder  for  internal  auditors  to  attempt 
that  task.     External  auditors  share  a  common  goal.     They  are  looking 
to  express  an  opinion  on  the  financial  statements  of  an  organization. 
Internal  auditors  have  a  much  more  variable  charter.     Their  role  and 
the  scope  of  their  activities  are  both  established  by  management. 
It  is  difficult  for  an  outside  group  to  dictate  standards  for  the 
internal  audit  function.     In  this  particular  workshop  the  approach 
to  be  taken  in  establishing  standards  depends  on  how  you  define 
security.     From  the  material  that  was  distributed  in  advance,  it 
app^ears  a  very  broad  definition  will  be  utilized.     To  the  extent  that 
this  group  is  able  to  develop  useful  standards,  it  will  be  a  very 
positive  forward  step. 

3.2  Qualifications  and  Training 

This  is  another  challenging  topic.     It  is  very  difficult  to  define 
the  qualifications  and  training  required  in  the  field  of  computer 
security  since  there  is  no  accepted  common  body  of  knowledge.  Perhaps, 
a  precise  definition  would  be  premature.     Professional  qualifications 
and  standards  evolve  very  slowly.     They  are  coming,  but  it  certainly 
will  be  a  while  before  a  consensus  is  formed.     It  is  very  hard  to 
predict  when  we  will  be  able  to  have  meaningful  standards  for 
professional  qualification  in  a  specialty  such  as  computer  security. 
The  group  working  on  this  topic  should  try  to  keep  their  recommenda- 
tions at  the  general  level.     It  would  be  a  mistake  to  try  and 
establish  a  strict  set  of  qualification  and  training  standards  this 
early  in  the  game.     It  would  be  better  to  start  slow  and  build  upon 
that  foundation. 
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3.3    Security  Administration 

This  is  a  relatively  new  area  as  it  relates  to  EDP.     A  thorough 
discussion  of  this  topic  should  prove  to  be  quite  useful.     There  is 
a  need  for  a  definition  of  the  duties,  responsibilities,  and  organi- 
zation of  the  security  administration  function.     While  this  material 
may  only  be  of  interest  to  very  large  organizations,  it  will  certainly 
be  helpful.     We  need  to  develop  audit  approaches  and  techniques  that 
can  be  applied  to  a  review  of  the  security  administration  function, 
so  guidelines  in  this  area  will  be  particularly  useful. 

3.^    Audit  Considerations  In  Various  System  Environments 

The  environment  has  a  decided  impact  on  audit  considerations, 
but  what  is  that  impact?    This  is  not  an  easy  question  to  answer. 
This  group  will  find  they  have  been  given  a  very  tough  assignment. 
Within  the  current  state  of  the  art  we  cannot  be  too  definitive 
in  providing  guidance.     To  date,  no  one  has  done  much,  if  anything, 
in  this  particular  area.     Some  thoughtful  consideration  of  this  topic 
should  prove  to  be  extremely  helpful  and  will  serve  as  a  useful 
starting  point  for  further  work. 

3.5  Administrative  and  Physical  Controls 

This  seems  to  be  a  strange  combination  of  topics.  External 
auditors  would  not  lump  these  two  together,  but  it  may  be  useful 
to  consider  them  in  tandem.     Yet,  it  may  prove  to  be  a  time  consuming 
task.     Administrative  and  physical  controls  cover  a  very  wide 
range  of  topics.     The  group  has  been  directed  to  place  their  emphasis 
on  those  areas  that  are  not  well  defined  in  the  existing  literature. 
They  may  find  it  difficult  to  identify  controls  that  are  new  or 
unique . 

3.6  Program  Integrity 

Audit  approaches  and  techniques  to  evaluate  the  security  of 
operating  systems,  data  base  management  systems,  and  application 
programs  are  to  be  covered.     The  members  of  this  session  will  consider 
the  problems  involved  in  establishing  integrity  in  these  three  areas. 
It  is  easy  to  consider  the  problems,  but  defining  the  audit  techniques 
to  evaluate  integrity  will  be  quite  a  challenge.     The  results  of  this 
group's  deliberations  will  certainly  be  of  interest. 

3.7  Data  Integrity 

This  is  a  more  familiar  topic.     Auditors,  particularly  external 
auditors,  have  been  deeply  involved  in  reviewing  and  evaluating 
data  integrity  for  quite  some  time.     The  group  has  been  asked  to 
identify  and  discuss  data  integrity  techniques  that  are  not  well 
covered  in  current  literature.     This  may  prove  to  be  a  tough  assignment. 
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The  literature  is  quite  complete  and  it  will  "be  surprising  if  the  group 
can  develop  very  much  that  is  new  in  this  area. 

3.8  Communications 

Most  auditors  lack  an  in-depth  expertise  in  the  field  of 
commionications  security.     The  developments  of  electronic  funds  transfer 
systems  and  distributed  processing  systems  will  make  this  topic  one 
that  is  of  considerable  importance.     Even  if  effective  security  is 
implemented  in  all  other  aspects  of  a  system,  the  entire  ball  game 
could  be  lost  through  a  data  communications  security  fault.  Guidance 
in  this  area  should  prove  to  be  of  immense  help  to  the  audit  community 
in  defining  some  of  its  future  tasks. 

3.9  Post  Processing  Audit  Tools  and  Techniques 

A  great  deal  of  information  is  recorded  on  the  journals  and  logs 
maintained  by  most  of  today's  computer  systems.     Auditors  face  a 
major  problem  in  determining  what  information  is  available  and 
deciding  how  to  get  at  it  and  use  it  to  accomplish  and  audit.  The 
group  has  been  asked  to  address  the  topic  of  the  need  for  new  techniques 
in  this  area.     They  may  conclude  there  is  little  need  for  new  techniques. 
Most  of  the  tools  that  an  auditor  requires  are  available.     They  were 
developed  for  use  by  systems  personnel.     The  auditor  needs  to  develop 
a  familiarity  with  what  is  available  and  to  gain  experience  in  its 
use.     The  group  addressing  this  topic  would  accomplish  a  great  deal  if 
they  are  able  to  highlight  the  areas  auditors  should  explore  and  at 
the  same  time,  provide  guidance  as  to  the  tools  they  might  employ. 

3.10  Interactive  Audit  Tools  and  Techniques 

In  this  particular  area,  the  needs  of  the  internal  auditor  are 
quite  different  from  those  of  the  external  auditor.  Internal 
auditors  usually  work  with  more  of  a  managerial  emphasis  and  they 
are  more  likely  to  have  a  need  for  on-line  analysis  of  data.  CPAs 
on  the  other  hand,  usually  perform  their  work  as  of  a  particular 
point  in  time.     Their  needs  are  usually  more  static  in  natiire.  How- 
ever, that  may  change.     The  growth  of  EFTS  and  distributed  processing 
may  make  interactive  auditing  a  more  important  area.     Both  internal 
and  external  auditors  will  be  interested  in  the  deliberations  of 
this  group. 


SUMMARY 


The  session  theme.  Audit  and  Evaluation  of  Computer  Security, 
is  a  timely  one.     The  topics  that  have  been  proposed  for  discussion 
are  all  of  current  interest  and  deal  with  areas  that  are  of  importance 
to  the  audit  community.     To  date,  the  known  financial  losses  related 
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to  data  security  failures  are  quite  small.     However,  logically,  these 
losses  are  bound  to  increase.     Consideration  of  the  topics  outlined 
for  this  workshop  will  provide  a  better  basis  for  defining  our  current 
problems  and  developing  the  techniques  we  will  need  to  cope  with  an 
expanding  technology. 
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EDITORS'  NOTE 


A  breif  biography  of  the  Session  Chairperson  follows: 

Mr.  William    E.  Perry  is  the  Director  of  EDP  and  Research  for  the 
Institute  of  Internal  Auditors  and  serves  as  staff  liaison  for  the  In- 
ternational Committees  on  EDP  Auditing  and  Research.    Prior  to  joining 
the  Institute,  he  was  Supervisor  of  Corporate  Computer  Auditing  for 
Eastman  Kodak  Company.    He  has  also  held  positions  with  Arthur  Young  & 
Company,  Ft.  Richie,  and  Price  Waterhouse  &  Company.    He  is  a  graduate 
of  Clarkson  College,  holds  a  MBA  from  Rochester  Institute  of  Technology 
and  a  MBd  from  the  University  of  Rochester.    He  is  a  Certified  Public 
Accountant  (NY)  and  a  Certified  Internal  Auditor.    He  is  a  member  of  the 
Computer  Services  Executive  Committee  and  the  Auditing  Advanced  EDP  Sys- 
tems Task  Force  of  the  AICPA,  a  member  of  the  Board  of  Directors  of  the 
American  Federation  of  Information  Processing  Societies,  and  past  com- 
mittee chairman  of  the  GUIDE  International  PL/1  Committee.    He  was  a 
professor  of  data  processing  at  Monroe  Community  College.    His  most  re- 
cent publications  include:    "Pre-Occurrence  Auditing--Building  Control 
Into  the  Audit  Program,"  Bank  Administration  (Jan.  &  Feb.,  '75)  and  nu- 
merous contributions  to  EDPACS  on  subjects  of  EDP  audit  and  control. 


The  charge  given  to  this  session  was: 

INTERNAL  AUDIT  STANDARDS:    Develop  a  proposed  statement  of  audit 
standards  for  computer  security  considering  (a)    the  role  of  the 
internal  auditor,  and  (b)    application  of  traditional  audit  stan- 
dards. 

Computer  security  is  a  very  complex  subject  that  must  be  considered  from 
a  total  system  perspective.    It  involves  all  the  controls  necessary  to 
ensure  (1)    the  accuracy  and  reliability  of  the  data  maintained  on  or 
generated  by  an  automated  data  processing  system,  and  (2)    the  protec- 
tion of  the  organizational  assets  to  include  the  hardware,  software,  and 
data  from  all  anticipated  threats  or  hazards. 

This  session  is  to  consider  the  responsibilities  of  the  internal  auditor 
in  evaluating  computer  security  throughout  the  developmental  and  opera- 
tional life  cycle  of  an  automatic  data  processing  system.    The  AICPA 's 
Statement  on  Auditing  Standards  No.  3  entitled,  "The  Effects  of  EDP  on 
the  Auditor's  Study  and  Evaluation  of  Internal  Control"  should  be  con- 
sidered for  use  as  a  departure  point  for  this  session. 


The  consensus  report  that  follows  was  developed  and  reviewed  by  the  ma- 
jority of  the  membership  of  this  session. 
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Supplemental  Standards  for  Internal  Auditor's  Expanded 
Role  in  Reviewing  Computer  Systems  and  their  Development 

A  Consensus  Report 


William  E.  Perry,  Fred  L.  Lilly,  D.  L.  Scantlebury, 
Ken  Pollock,  T.  Q.  Stevenson,  Frank  S.  Sato 


1.  INTRODUCTION 


1.1  Automated  Systems  Effect  on  Environment 

The  computer  has  substantially  altered  the  methods  by  which  data 
processing  systems  operate  and  are  controlled  and  audited.    The  oppor- 
tunities for  personal  review  and  clerical  checking  have  declined  as  the 
collection  and  subsequent  uses  of  data  are  changed.    The  changes  are 
the  result  of  moving  from  manual  procedures  performed  by  individuals 
familiar  with  both  the  data  and  the  accounting  process  to  high  volume, 
automated  techniques  performed  by  individuals  unfamiliar  with  both  the 
data  and  accounting  practices. 

The  introduction  of  data  processing  equipment  frequently  requires 
that  the  recording  and  processing  functions  be  concentrated  in  depart- 
ments that  are  separate  from  the  origin  of  the  data;  it  may,  however, 
eliminate  the  separation  of  some  of  the  responsibilities  that  previously 
characterized  the  record  keeping  function.    A  trend  toward  the  integra- 
tion of  operating  and  financial  data  into  organization-wide  information 
systems  of  data  bases  also  eliminated  independent  records  that  might 
previously  have  provided  a  source  of  comparative  data.    At  the  same 
time,  such  integrated  information  systems  can  become  the  basis  for  more 
vital  and  timely  management  decisions. 

Computerization  has  reduced  substantially  the  time  available  for 
the  review  of  transactions  before  their  entry  into  the  accounting 
records.    As  a  result,  in  poorly  controlled  systems  the  opportunity 
for  discovering  errors  or  fraud  before  they  have  an  impact  on  opera- 
tions may  be  reduced,  especially  in  the  case  of  real-time  and  data  base 
systems.    This  has  increased  the  importance  of  internal  control  pro- 
cedures [1].    It  also  affects  the  work  the  auditor  must  perform.  An 
important  aspect  of  this  work  is  reviewing  the  adequacy  of  computer 
security. 

1.2  Computer  Security  Defined 

Computer  security  is  a  very  complex  subject  that  must  be  considered 
from  a  total  system  perspective.    It  involves  all  the  controls  necessary 
to  ensure  (1)  the  accuracy  and  reliability  of  the  data  maintained  on  or 
generated  by  an  automated  data  processing  system,  (2)  an  appropriate 
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degree  of  protection  of  the  organizational  assets  to  include  the  hard- 
ware, software,  and  data  from  all  significant  anticipated  threats  or 
hazards,  and  (3)  the  economy  and  efficiency  of  computer  operations. 

Computer  security  does  not  include  (1)  the  justification  of  a 
computer  system,  (2)  the  full  range  of  meeting  all  management  objectives, 
and  (3)  determining  an  acceptable  level  of  risk  for  an  organization, 
but  all  are  areas  for  audit  involvement. 


1.3    Discussion  of  Audit  Involvement  in  Computer  Security 

The  concept  of  accountability  is  inherent  in  government  and  non- 
government audits.    Any  audit  could  encompass  the  three  elements  bearing 
on  accountability,  which  are: 


1.  Finance  and  compliance 

2.  Economy  and  efficiency 

3.  Program  results 

From  the  standpoint  of  the  auditor  reviewing  security,  the  elements 
of  both  compliance  and  program  results  are  within  bounds.  (Efficiency 
and  economy  may  be  adversely  affected  by  a  tight  computer-security 
requirement.)    There  may  be  specific  standards  or  regulatory  require- 
ments governing  security  aspects  of  an  operation  which  should  be 
reviewed  for  compliance,  and  in  evaluating  the  program  results  of  an 
operation,  security  may  be  an  important  factor.    Similarly,  in  audits 
performed  by  CPA  firms  and  the  GAO,  attention  is  given  to  the  adequacy 
of  control  over  assets,  and  this  may  well  involve  the  security  controls 
over  information  held  by  the  organization.    Internal  auditors  should 
be  concerned  with  the  adequacy  of  control  of  organization-held  infor- 
mation. 


A  separate  auditing  standard  per  se  to  cover  the  auditor's  work  in 
this  area  is  not  warranted.    However,  another  mechanism  is  needed  to 
draw  the  auditor's  specific  attention  to  the  problem  of  computer 
security  and  make  him  aware  of  his  responsibilities.    The  mechanism  may 
include  items  such  as  a  commentary,  clarification,  or  interpretation  of 
existing  standards. 

The  AICPA  used  this  means  when  it  issued  Statement  of  Auditing 
Standards  (SAS)  No.  3  "The  Effect  of  EDP  on  the  Auditors'  Study  and 
Evaluation  of  Internal  Control."    The  basic  CPA  audit  standards  which 
have  served  so  well  without  modification  for  so  long  were  not  changed 
with  the  advent  of  the  computer,  but  the  SAS  amplified  and  interpreted 
the  standards  as  it  related  to  EDP.    We  have  chosen  to  use  the  term 
"supplemental  standard"  in  discussing  the  expanded  role  of  the  internal 
auditor  in  this  area. 
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1.4    Changing  Auditor  Requirement 

When  internal  auditors  function  in  a  computerized  environment, 
their  audit  responsibility  needs  to  encompass  the  following: 

1.  Provide  guidance  to  data  processing  and  user  personnel 
for  creating  the  mechanism  for  auditable  systems 

2.  Determine  that  internal  controls  in  computerized  appli- 
cations are  operative  and  effective  by  reviewing  and 
testing  those  controls. 


2.0    SUPPLEMENTAL  STANDARDS  FOR  COMPUTER  INTERNAL  AUDIT  WORK 


2.1  General 

A  computerized  environment  does  not  create  a  need  for  new  audit 
standards.    The  current  internal  audit  standards  as  set  forth  in  the 
GAO  pamphlet  "Standards  for  Audit  of  Governmental  Organizations, 
Programs,  Activities,  &  Functions,"  are  basically  appropriate  for  audits 
of  the  data  processing  function.    What  is  needed  are  supplements  to 
those  standards  that  specify  the  additional  tasks  the  auditor  must 
perform  in  a  computerized  environment  to  meet  the  basic  standards. 

Three  areas  have  been  identified  for  the  purposes  of  supplementing 
those  standards.    These  are  audit  involvement  in: 

1.  Systems  development 

2.  Operational  systems  (application  controls) 

3.  Physical  security  and  general  controls 

2.2  Supplemental  Standard  for  Systems  Development 

The  internal  auditor  shall  be  involved  in  the  development  of  new 
data  processing  systems  or  significant  modification  of  existing  ones 
with  the  objectives  of  seeing  that  such  systems: 

1.  Include  the  controls  necessary  to  protect  against  theft 
and  serious  error 

2.  Provide  the  audit  trails  needed  for  management,  auditors, 
and  operational  review 

3.  Faithfully  carry  out  the  policies  management  has  prescribed 
for  the  system 
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4.  Will  provide  an  efficient  and  economical  system 

5.  Are  in  conformity  with  applicable  legal  requirements 

6.  Are  documented  in  a  manner  that  will  provide  an  understanding 
of  the  system  required  for  maintaining  and  auditing  the  system 

2.2.1  Commentary 

The  system  development  process  includes  the  definition  of  proces- 
sing applications  to  be  carried  out  by  a  computer,  design  of  the  pro- 
cessing steps  to  be  followed,  determination  of  the  data  input  and  files 
that  will  be  required,  and  specifications  for  individual  program's 
input  data  and  output. 

Auditor  involvement  is  important  in  the  design  of  an  application. 
It  is  needed  because  the  design  must  provide  for  necessary  control  pro- 
cedures and  produce  the  reports  and  data  files  which  will  be  needed  for 
audit  purposes  after  the  system  becomes  operational. 

Requirements  for  an  EDP  system  should  be  established  by  management 
and  it  is  the  auditor's  responsibility  to  determine  whether  or  not  these 
policies  are  being  carried  out  in  the  design  and  whether  or  not  the 
design  conforms  with  applicable  legal  requirements.    This  will  require 
the  auditor  to  ascertain  the  nature  of  the  requirements  set  by  manage- 
ment, and  whether  or  not  the  requirements  are  being  met. 

The  auditor  should  ascertain  that  an  appropriate  approval  process 
is  being  followed  in  development  of  new  systems  and  making  modifications 
to  existing  systems.    In  doing  this  the  auditor  should  consider  the  need 
for  approval  of  system  design  by  data  processing  management,  user  groups, 
and  other  user  groups  whose  data  and  reports  may  be  affected. 

The  auditor  should  also  determine  whether  or  not  management  requires 
documentation  sufficient  to  define  the  processing  that  must  be  performed 
by  programs  in  the  system,  data  files  to  be  processed,  reports  to  be 
prepared  for  users,  operating  instructions  for  use  by  computer  operators, 
and  user  group  instructions  for  preparation  and  control  of  data.  The 
auditor  should  also  ascertain  whether  or  not  management  policy  provides 
for  testing  sufficient  to  give  assurance  that  reliance  can  be  placed  in 
the  system  before  the  system  is  used  for  production  purposes. 

The  auditor  should  review  provisions  for  security  required  by  man- 
agement to  protect  data  against  unauthorized  access  and  modification. 
The  auditor  should  also  consider  whether  the  benefits  of  the  system  jus- 
tify its  costs  whenever  the  benefits  can  be  quantitatively  measured.  In 
all  cases,  the  auditor  should  be  alert  to  whether  the  system  design  will 
provide  for  an  economical  and  efficient  system  and  should  investigate 
instances  in  which  it  appears  more  economical  or  efficient  methods  can 
be  used. 


3-6 


After  reviewing  management  policies,  the  auditor  should  examine 
approvals,  documentation,  test  results,  and  cost  studies  and  other  data 
to  determine  the  extent  to  which  management  policies  are  being  followed. 
The  auditor  should  keep  a  close  association  with  the  system  during  the 
development  phase  [2]  but  should  not  become  a  part  of  the  design  team-- 
except  to  the  extent  of  recommending  controls--in  order  to  maintain 
proper  objectivity. 

The  auditor  should  report  in  writing  on  both  the  adequacy  of  the 
policies  and  the  extent  to  which  those  policies  are  being  followed  as 
determined  by  the  auditor's  examination.    The  auditor  should  specifi- 
cally comment  on  all  findings  which  require  corrective  action  and  should, 
to  the  extent  possible,  submit  recommendations  for  appropriate  action. 

2.3    Supplemental  Standard  for  Operational  Systems  (Application  Controls) 

The  internal  auditor  should  review  the  installed  data  processing 
applications  to  determine  reliability  in  processing  data  in  a  timely, 
accurate,  and  complete  manner. 

Audit  objectives  should  be  to: 

1.  Determine  whether  the  installed  application  conforms  to  stan- 
dards and  the  latest  approved  design  specifications,  and 

2.  Disclose  possible  weaknesses  in  the  installed  application 
through  periodic  audits  designed  to  test  internal  control 
and  the  reliability  of  the  data  produced. 

2.3.1  Commentary 

The  transition  from  mechanical  data  processing  (MDP)  to  electronic 
data  processing  (EDP  or  ADP)  occasions  the  need  for  revision  in  tradi- 
tional audit  standards.    More  specifically,  the  complexity  and  far- 
reaching  scope  of  EDP  systems  require  that  the  internal  audit  give 
greater  attention  to  the  system  which  processes  data,  as  well  as  to  the 
data;  the  theory  being  that,  if  the  system  is  secure,  the  data  processed 
and  reported  will  be  reliable. 

Supplemental  standard  one  deals  with  the  internal  auditor's  involve- 
ment in  the  development  of  the  system  specifications  for  the  purpose  of 
assuring  that  computer  security  has  been  adequately  considered--with 
an  appropriate  risk  analysis--and  that  the  more  traditional  internal 
controls  over  data  processing  are  included. 

Audit  compliance  with  supplemental  standard  two  provides  assurance 
that  the  approved  specifications,  with  all  built-in  internal  controls, 
etc.,  have  been  installed  as  intended  on  specific  applications. 
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It  further  provides  that  the  auditor  institute  periodic  internal 
audits  designed  to  probe  the  installed  application  for  weaknesses, 
changed  circumstances  in  risk  exposure,  etc.,  with  the  intention  of 
stimulating  corrective  modifications  of  specifications  and  improving 
the  installed  applications.    In  these  periodic  audits,  the  internal 
auditor's  consideration  of  internal  controls  is  particularly  important. 
Also,  the  auditor  must  be  mindful,  when  conducting  periodic  tests  of 
the  installed  system,  that  there  are  no  guarantees  that  the  system  will 
continue  to  operate  in  accordance  with  the  latest  approved  specifi- 
cations . 

As  a  part  of  the  testing  of  reliability  of  data  produced,  the 
auditor  will  normally  examine  supporting  documentation  for  selected 
transactions  and  test  the  clerical  accuracy  of  the  manner  in  which 
transactions  have  been  entered  and  summarized  and  to  test  compliance 
with  control  procedures.    In  addition,  auditors  may  wish  to  test 
selected  data  files  to  identify  possible  exception  conditions  and 
accuracy  of  data  conversion  or  capture.    If  the  data  records  are 
maintained  in  machine-readable  condition,  the  auditor  should,  where 
appropriate,  make  use  of  computer  assisted  audit  techniques  in  testing 
data  records. 

Because  of  the  significant  potential  for  fraud  and  other  irregu- 
larities in  computer  systems,  the  internal  auditor  must  be  alert  to 
the  potential  of  fraud.    Although  auditing  for  fraud  should  not 
necessarily  be  the  primary  objective,  the  current  environment  dictates 
that  detection  of  major  frauds  should  be  one  of  the  objectives  of 
internal  auditing. 

2.4    Supplemental  Standard  for  Physical  Security  and  General  Controls 

The  internal  auditor  should  be  involved  in  review  of  the  general 
controls  present  in  data  processing  systems  to  assure  that  their  exis- 
tence and  operation  are  in  accordance  with  management  direction  and 
legal  requirements,  and  are  operating  effectively  to  provide  security 
over  the  data  being  processed. 

2.4.1  Commentary 

The  auditor  should  distinguish  between  general  EDP  controls,  which 
are  normally  applicable  to  all  processing  being  carried  out  within  the 
installation,  and  application  controls  (covered  in  Section  2.3),  which 
may  vary  between  applications  and  are  therefore  reviewed  on  an  indivi- 
dual application  basis.  In  reviewing  general  controls,  auditors  review 
and  evaluate  controls  in  several  areas,  and  consider  the  effectiveness 
of  the  general  controls  in  performing  the  review  of  application  controls. 

Authority  and  responsibility  must  be  delegated  within  the  organi- 
zation in  such  a  manner  that  the  objectives  of  the  organization  can  be 
met  with  efficiency  and  effectiveness.    The  auditor  should  review  the 
organization,  delegation  of  authority,  responsibilities,  and  separation 
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of  duties  in  the  organization  to  determine  whether  or  not  functional 
lines  of  authority  are  designed  to  meet  the  organization's  objectives, 
and  whether  or  not  the  separation  of  duties  provides  for  a  relatively 
strong  level  of  internal  control.    Separation  of  duties  should  provide 
for  separation  between  program  and  systems  development  functions,  com- 
puter operations,  control  over  input  of  data,  and  control  group  respon- 
sible for  maintaining  application  controls. 

In  reviewing  the  separation  of  duties,  the  auditor  should  evaluate 
the  control  strengths,  and  report  on  any  weaknesses  resulting  from 
inadequate  separation  of  duties.    The  separation  of  duties  may  be 
enhanced  by  policies  requiring  periodic  rotation  of  duties  and  mandatory 
vacations.    The  auditor  should  also  review  whether  such  policies  are 
being  followed. 

Adequate  physical  facilities  and  other  resources  (such  as  ade- 
quately trained  personnel,  supplies,  and  power)  are  necessary  for  the 
organization  to  meet  its  processing  objectives.    The  auditor  should 
review  these  facilities  to  determine  whether  or  not  the  organization 
has  adequate  facilities  for  meeting  its  needs. 

Personnel  management,  including  supervision  of  personnel,  moti- 
vation of  personnel,  and  professional  development  is  an  integral  part 
of  the  successful  management  of  the  data  processing  function.  The 
auditor  should  review  these  policies  to  ascertain  whether  or  not  the 
necessary  management  policies  exist  and  determine  whether  or  not  they 
are  properly  followed. 

The  auditor  should  review  provisions  for  physical  security  of  the 
computer  hardware,  computer  programs,  data  files,  and  personnel  to 
ascertain  the  extent  of  security  being  maintained.    This  review  should 
include  not  only  the  computer  equipment  present  in  the  central  proces- 
sing facility,  but  also  extends  to  computer  terminals  and  other  peri- 
pheral equipment.    In  reviewing  physical  security  of  computer  hardware, 
the  auditor  should  consider  the  extent  to  which  there  are  adequate 
contingency  plans  for  continuity  of  processing  in  the  event  of  a  dis- 
ruption of  data  processing  functions.    This  should  include  not  only 
provisions  for  hardware  backup  but  detailed  plans  for  making  use  of 
backup  equipment,  transporting  personnel,  programs,  forms,  and  data 
files  to  an  alternate  processing  location,  and  other  contingency  plans 
necessary  for  this  mode  of  operation.    The  auditor  should  also  consider 
the  extent  to  which  this  contingency  plan  has  been  exercised. 

In  reviewing  physical  security  over  files,  the  auditor  should  de- 
termine whether  or  not  data  and  program  file  libraries  are  maintained  by 
personnel  who  do  not  have  access  to  computers  and  computer  programs, 
whether  or  not  the  library  is  secure,  whether  or  not  computer  operators 
and  other  personnel  have  access  to  the  library,  and  provisions  for 
backup  of  files  (including  off-site  backup).    In  the  case  of  files  nor- 
mally maintained  on-line,  the  auditor  should  consider  the  extent  to 
which  these  files  are  protected  by  authorization  controls  within  the 
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operating  system  and  whether  backup  copies  of  files  are  maintained  on  a 
regular  basis.    As  a  part  of  the  review  of  procedures  for  maintaining 
backup  copies  of  files,  the  auditor  should  review  procedures  for 
ensuring  that  backup  files  are  properly  identified,  labeled,  and  con- 
tents verified  to  ensure  that  the  backup  medium  is  complete  and  accurate. 

Since  computer  systems  are  most  often  controlled  by  systems  soft- 
ware and  particularly  operating  systems,  and  since  systems  software 
provides  for  file  handling  capabilities,  multiprogramming  capabilities, 
file  label  checking,  and  many  other  authorization  controls,  the  systems 
software  is  an  integral  part  of  the  control  over  computer  processing. 
The  auditor  should  be  aware  of  the  types  of  controls  which  the 
operating  system  and  other  systems  software  can  exercise  and  should 
ascertain  the  extent  to  which  those  controls  have  been  implemented. 
As  a  part  of  this  review,  the  auditor  should  be  aware  of  the  fact  that 
personnel  responsible  for  maintenance  of  the  systems  software,  and 
other  persons  with  the  ability  to  make  unauthorized  modifications  to 
this  software,  may  either  intentionally  or  accidentally  cause  specific 
control  features  within  that  software  to  become  ineffective. 

Computer  hardware  frequently  has  capabilities  designed  into  it  for 
detection  of  erroneous  conditions  related  to  hardware  malfunctions 
rather  than  program  malfunctions.    The  auditor  should  be  aware  of  the 
extent  to  which  the  installation  relies  upon  these  hardware  controls, 
the  extent  to  which  the  operating  system  utilizes  these  controls,  and 
the  manner  in  which  hardware  errors  detected  in  a  system  are  reported 
within  the  installation  as  well  as  procedures  for  taking  corrective 
action. 

2.5    Other  Audit  Requirements 

The  auditor  should  review  the  organization's  economic  justification 
and  analysis  for  procurement  of  all  data  processing  equipment.  This 
will  include  a  thorough  review  of  the  cost-benefit  analyses  developed 
by  the  data  processing  staff  in  conjunction  with  users  of  systems  that 
are  to  be  operated.    The  cost  justification  developed  by  management 
should  encompass  a  reasonable  level  of  risk  analysis  to  assure  that  the 
equipment  being  purchased  is  in  fact  commensurate  with  the  needs  and 
probability  of  exposure  or  loss.    For  example,  it  may  be  that  the 
requirements  to  comply  with  the  Privacy  Act  may  necessitate  adoption  of 
special  techniques  to  prevent  accidental  or  intentional  disclosure  of 
data.    This  may  be  accomplished  in  a  number  of  ways;  the  method  chosen 
should  be  that  which  is  most  cost  effective  for  the  intended  purpose. 

3.0    RECOMMENDED  COURSE  OF  ACTION 


The  auditor  should  review  the  organization's  ADP  system  acquisition 
document  for  its  standards.    These  specifications  then  should  be  com- 
pared to  any  applicable  ones  of  the  organization  and  to  what  is  actually 
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implemented  on  the  operating  equipment  and  software.    Any  deviations 
should  be  documented  by  an  approved  waiver  or  other  release. 

The  following  three  actions  are  suggested  for  fostering  the 
acceptance  and  implementation  of  the  previously  stated  three  supplemen- 
tal internal  auditing  standards. 

1.  That  GAO  review  these  standards  and  consider  modifying 
their  standards  pamphlet  accordingly,  or  issuing 
separate  supplemental  material  encompassing  the 
supplemental  standards. 

2.  That  the  supplemental  standards  be  presented  to 
the  Federal  Audit  Executives  Council  for  review 
and  endorsement. 

3.  That  NBS  consider  these  supplemental  standards 

in  preparing  FIPS  guidelines  for  systems  development, 
operational  systems,  physical  security  and  general 
control s. 
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EDITORS'  NOTE 


A  brief  biography  of  the  Session  Chairperson  follows: 

Mr.  C.  0.  Smith  is  an  Assistant  Director  of  the  Logistics  and 
Communications  Division  of  the  United  Stated  General  Accounting  Office 
in  Washington,  D.C.    He  has  over  20  years  of  broad  and  in-depth  experience 
working  with  all  levels  of  operating  and  management  personnel  within 
Federal,  state,  and  local  governments,  and  private  industry.    He  is 
responsible  for  planning,  directing,  coordinating,  and  participating  in 
world-wide  evaluations  of  information  handling  operations  involving 
administrative,  scientific,  and  military  applications  of  computers.  His 
work  has  concentrated  on  assessing  all  aspects  of  information  handling 
including  system  and  program  project  planning,  management  analysis, 
design,  implementation,  and  operation  on  a  world-wide  basis.    During  the 
past  10  years  he  has  focused  on  a  wide  variety  of  different  systems  and 
programs  including  but  not  limited  to  command  and  control,  payroll, 
accounting,  logistical,  and  management  information  applications. 
Previously  he  specialized  in  assessing  the  performance  of  individual  data 
processing  installations.    His  degrees  are  in  Accounting  (California 
State  University-Fresno,  B.S.)  and  in  Business  Administration  and  Manage- 
ment Information  Systems  (The  American  University,  M.B.A.).    He  is  a 
Certified  Internal  Auditor  (CIA)  and  member  of  the  Institute  of  Internal 
Auditors,  the  Society  for  Management  Information  Systems,  Military  Opera- 
tions Research  Society,  and  the  EDP  Auditors  Association,  Inc.    His  most 
recent  pertinent  publication,  with  H.  J.  Podell  and  B.  Knowles,  is 
Management  Auditing  of  Computer  Operations:    A  Tutorial,  New  York,  IEEE, 
Inc.,  1976. 


The  charge  given  to  this  session  was: 

QUALIFICATIONS  AND  TRAINING:    What  are  the  qualifications  and 
training  necessary  to  conduct  audits  of  computer  security? 

The  first  general  auditing  standard  of  the  AICPA  is  as  follows: 
"The  examination  is  to  be  performed  by  a  person  or  persons  having  adequate 
technical  training  and  proficiency  as  an  auditor."    (SAS  No.  1,  section 
150.20).    SAS  No.  3,  paragraph  4,  expands  on  this  standard  by  stating  that, 
"Situations  involving  the  more  complex  EDP  applications  ordinarily  will 
require  that  the  auditor  apply  specialized  expertise  in  EDP  in  performance 
of  the  necessary  audit  procedures." 

The  task  of  this  session  is  to  identify  and  define  the  specialized 
expertise  necessary  to  conduct  evaluations  of  computer  security  together 
with  the  training  and  experience  needed  to  achieve  the  appropriate  level 
of  expertise.    Consideration  should  be  given  to  the  full  spectrum  of 
controls  from  the  evaluation  of  simple  physical  safeguards  to  an  analysis 
of  the  protective  features  of  system  software. 


The  consensus  report  that  follows  was  developed  and  reviewed  by 
the  entire  membership  of  this  session. 


4-2 


INTRODUCTION 


The  computer  is  rapidly  becoming  one  of  our  most  useful  tools. 
In  the  slightly  more  than  two  decades  since  its  introduction,  the 
computer  has  made  a  profound  change  in  many  facets  of  our  lives.  It 
assists  us  in  predicting  the  outcome  of  our  elections;  it  guides  our 
astronauts  in  space  to  compensate  for  man's  relatively  slow  reaction 
time;  it  controls  the  flow  of  our  traffic  on  the  streets,  on  rails, 
and  in  the  air;  it  is  used  to  help  diagnose  our  ills;  forecast  our 
weather;  compute  our  bank  balances;  and  hundreds  of  other  chores  which 
we  could  not  even  undertake  before  its  advent. 

Predictions  on  the  future  use  of  the  computer  are  many  and  varied 
because  the  ingenuity  of  man  knows  no  dimensions  of  time  when  dealing 
with  the  possibilities  of  pressing  back  the  frontiers  of  his  ignorance. 
Since  the  expected  growth  in  the  use  of  the  computer  will  contine  to 
be  nothing  less  than  phenomenal,  managers  and  other  users  will  tend 
to  become  much  more  dependent  on  the  computer  than  they  have  been  in 
the  past.    As  these  individuals  become  more  dependent  on  the  computer, 
opportunities  for  its  misuse  and  abuse  will  also  increase.    As  the 
opportunities  for  computer  misuse  and  abuse  increases,  managers  and 
those  individuals  who  will  audit  and  evaluate  computer  operations, 
particularly  computer  security,  must  be  highly  qualified  and  well 
trained.    These  individuals  must  be  familiar  with  the  symptoms  of 
potential  disaster  so  that  efficient  and  effective  corrective  action 
plans  may  be  initiated,  implemented,  and  maintained  before  their 
computer  systems  become  a  nightmare  of  error  and  financial  loss.  In 
addition,  these  individuals  must  be  familiar  with  the  methods  used  to 
protect  data  from  all  anticipated  threats  or  hazards. 

For  these  reasons,  the  basic  question  addressed  during  this 
session  of  the  workshop  was  "What  are  the  qualifications  and  training 
an  individual  needs  to  conduct  reliable  audits  of  computer  security?" 
Specifically,  this  task  consisted  of  identifying  and  defining  the 
specialized  expertise  necessary  to  properly  conduct  evaluations  of 
computer  security  together  with  the  requisite  training  needed  to 
achieve  that  level  of  expertise.    Stated  more  simply.  What  is  the 
common  body  of  knowledge  needed  to  do  this  work? 

CONSIDERATIONS  ASSOCIATED  WITH 
DEVELOPING  A  COMMON  BODY  OF  KNOWLEDGE 

For  our  purposes,  the  panel  considered  computer  security  from 
a  total  system  perspective;  that  is,  computer  security  involves  all 
the  controls  necessary  to  ensure  the  integrity,  accuracy,  and  reli- 
ability of  the  data  that  is  an  integral  part  of  an  automated  data 
processing  system.    This  perspective  includes  all  the  controls 
established  over  the  acquisition,  processing,  storing,  and  dissemina- 
tion of  information.    The  panel  tempered  their  consideration  with  the 
knowledge  that  they  were  unaware  of  any  foolproof  system  of  evaluating 
computer  security  that  will  prevent  an  unauthorized  or  illegal  inter- 
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vention  or  penetration  of  an  automated  data  processing  system  by  a 
sophisticated  professional  and  technically  qualified  intruder. 


When  considering  the  appropriate  level  of  expertise  necessary  to 
conduct  these  audits,  the  panel  first  attempted  to  identify  the  common 
body  of  knowledge  that  an  individual  must  have  before  becoming  involved 
in  this  work  and  then  gave  extensive  consideration  to  the  complexities 
of  the  environment  in  which  the  individual  would  conduct  the  work.  The 
panel  assumed  that  the  individual (s)  conducting  these  evaluations  could 
have  their  basic  education  and  experience  in  any  generally  recognized 
discipline  such  as,  but  not  limited  to,  accounting,  business  adminis- 
tration, engineering,  operations  research,  computer  science,  or 
economics.    Each  of  these  disciplines  already  has  a  specified  body  of 
knowledge  identified  or  associated  with  it.    Since  individuals  with 
varying  backgrounds  and  experience  can  be  expected  to  conduct  these 
evaluations,  the  panel  could  not  assume  that  everyone  undertaking  this 
work  would  be  a  fully-qualified  professional  auditor.    Regardless  of 
an  individuals'  basic  education  and  experience,  audits  of  computer 
security  demand  a  solid  foundation  in  the  concepts  and  practices  of 
management  and  auditing  supplemented  by  a  solid  foundation  in  the 
fundamentals  of  data  processing  and  telecommunications,  including  an 
appreciation  of  hardware  and  software  capabilities  and  limitations. 
Depending  on  the  type,  nature  and  scope  of  the  audit,  an  individual 
will  require  varying  degrees  of  knowledge  and  experience  in  computer 
operations,  software  performance,  and  information  flows  into,  through, 
and  out  of  the  automated  data  processing  function.    The  more  complex 
the  system  being  evaluated  the  more  comprehensive  technical  knowledge 
will  be  required.    For  example,  if  a  major  segment  of  the  audit  is 
to  ascertain  the  integrity  of  a  computer  program  or  a  series  of  com- 
puter programs  the  auditor,  among  other  things,  should  be  thoroughly 
familiar  with  the  severity  of  the  potential  or  real  threats  that  can 
be  mounted  against  them.    As  outlined  in  Part  VIII  of  the  Proceedings, 
these  threats  include  but  may  not  be  limited  to  the  following: 

A.  Accidental  disclosure 

1.  Natural  failure  of  either  or  both  hardware  and  software 

2.  Human  error 

B.  Casual  unauthorized  access 

1.  Browser  discovered  flaws 

2.  Exploiter  (intruder)  seeks  flaws 

C.  Deliberate  attack 

1.  Thief  creates  flaws  (plants  trap  doors,  modifies  code) 

2.  Conspiracy  (the  conduct  of  a  planned  attack) 

3.  Irrational  employee 

Frequently  the  skills  needed  to  conduct  this  type  of  audit  do 
not  reside  with  a  single  individual.    In  this  situation  multidisci- 
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plinary  audit  teams  could  be  used.    A  mul tidiscipl inary  team  contains 
all  the  skills  and  experience  needed  for  a  specific  audit.    The  mul ti- 
discipl inary  team  approach  has  been  used  very  successfully  by  both 
governmental  and  non-governmental  organizations. 

In  addition,  it  was  the  panel's  view  that  they  should  not  overly 
concern  themselves  with  "who  will  conduct  the  audit"  and  that  they 
should  concentrate  their  efforts  on  identifying  the  common  body  of 
knowledge  needed  to  do  the  work.    Further,  the  panel  did  not  concern 
themselves  with  "who  would  provide  the  training."    It  was  the  panel's 
view  that  universities;  colleges;  the  Civil  Service  Commission;  the 
Interagency  Auditor  Training  Center;  the  Institute  for  Professional 
Education,  Inc.;  and  a  myriad  of  other  institutions  and  professional 
organizations  either  have  or  could  develop  courses,  seminars,  or 
workshops  that  would  meet  the  training  and  educational  needs  included 
in  that  common  body  of  knowledge. 

Finally,  the  panel  did  not  attempt  to  ascertain  the  costs  involved 
in  developing  the  needed  level  of  expertise  because  too  many  variables 
are  involved.    For  example,  the  costs  associated  with  developing  the 
needed  level  of  expertise  will  vary  substantially  depending  on  whether 
the  organization:    develops,  the  capability  in-house  by  training  their 
own  employees,  partially  develops  the  capability  in-house  by  training 
a  few  selected  employees  and  supplementing  this  capability  by  tempo- 
rarily hiring  the  additional  expertise  from  a  source  outside  the 
organization,  or  hires,  either  temporarily  or  on  a  continuing  basis, 
the  needed  expertise  from  an  outside  source  such  as  a  consulting  firm. 
Since  each  organization  and  each  individual  will  have  different 
training  needs,  an  organization  must  develop  its  own  program  to  obtain 
and  maintain  the  common  body  of  knowledge  needed  to  effectively  audit 
computer  security.    Perhaps  a  major  concern  here  is  not  how  much  does 
it  cost  to  develop  the  needed  level  of  expertise,  but  whether  the 
organization  can  afford  not  to  develop  it  in  the  light  of  the  in- 
creasing number  of  detected  and  reported  cases  of  computer  misuse  and 
abuse. 

When  developing  the  common  body  of  knowledge  needed  for  auditing 
computer  security,  the  panel  was  confronted  with  two  basic  problems. 
First,  there  is  the  problem  of  enhancing  the  basic  knowledge  and 
experience  of  those  who  will  conduct  the  audits;  and  second,  there  is 
the  problem  of  determining  the  extent  of  the  technical  training  needed 
by  each  individual  participating  in  the  audit.    Experience  has  shown 
that  there  are  at  least  three  levels  of  knowledge  required  for  this 
work.    There  is  a  general  level  of  knowledge  required  in  the  disci- 
plines of  management  and  auditing  concepts  and  practices.  Individuals 
graduating  from  a  recognized  university  or  college  with  a  degree  in 
business  administration  or  accounting  will  usually  have  reached  this 
level  of  knowledge.    These  individuals  will  generally  lack  a  solid 
foundation  in  the  fundamentals  of  data  processing  and  telecommunications 
and  will  have  to  acquire  this  knowledge  through  additional  training. 
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The  second  level  of  knowledge  requires  an  individual  to  develop 
a  solid  foundation  in  the  fundamentals  of  data  processing  and  tele- 
communications including  an  appreciation  of  hardware  and  software 
capabilities  and  limitation.    An  individual  graduating  from  a  recog- 
nized university  or  college  with  a  degree  in  a  discipline  such  as 
computer  science  will  normally  have  attained  this  level  of  knowledge. 
Such  an  individual  may  lack  a  solid  foundation  in  management  and 
auditing  concepts  and  practices  and  will  have  to  acquire  this  knowledge 
through  additional  training. 

The  third  level  of  knowledge  involves  the  development  of  a 
comprehensive  technical  knowledge  and  the  related  experience  to  audit 
the  more  sophisticated  aspects  of  a  computer  system.    For  example, 
this  level  of  knowledge  would  be  required  when  evaluating  the  vulner- 
ability of  an  operating  system  (monitor,  executive  system,  etc.)  for 
unauthorized  access  by  a  browser  or  skilled  exploiter  seeking  flaws 
in  the  system. 

With  these  requirements  in  mind,  the  panel  outlined  the  common 
body  of  knowledge  and  the  related  qualifications  and  training  they 
believed  to  be  necessary  to  conduct  reliable  audits  of  computer 
security.    The  outline  beginning  on  page  4-11  has  been  preceeded  by  a 
brief  description  of  the  importance  of  each  part  of  that  body  of 
knowledge. 

For  purposes  of  guiding  the  reader  the  outline  has  been  divided 
into  eight  parts  as  follows: 


1.  Computer  systems,  operations,  and  software 

2.  Data  Processing  techniques 

3.  Management  of  the  data  processing  function 

4.  Security  of  the  data  processing  function 

5.  Risk  analysis  and  threat  assessment 

6.  Management  concepts  and  practices 

7.  Auditing  concepts  and  practices 

8.  Additional  qualifications  needed  to  audit  computer 
security 


1.     COMPUTER  SYSTEMS,  OPERATIONS,  AND  SOFTWARE 


The  topics  covered  in  this  section  are  intended  to  provide  a  broad 
theoretical  foundation  necessary  for  an  individual  to  understand  the 
interrelationships  and  interactions  of  all  parts  of  a  computer  system. 
The  foundation  provided  by  these  topics  will  give  an  individual  a 
familiarity  with  the  way  computers  operate  and  the  interrelated  and 
essential  function  of  software.    These  general  principles  may  be 
applied  to  any  type  of  system  regardless  of  whether  it  is  a  batch, 
interactive,  on-line  or  distributive  system. 
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2.    DATA  PROCESSING  TECHNIQUES 


Dramatic  advances  in  data  processing  techniques  have  taken  place 
within  the  past  two  decades  and  each  year  brings  still  faster  and  more 
efficient  methods  for  processing  data.    Programming  languages  have 
proliferated,  data  management  has  become  more  efficient  and  file 
processing  techniques  have  made  it  possible  to  store  and  retrieve  vast 
amounts  of  data.    This  rapid  evolution  of  data  processing  requires  an 
individual  not  only  to  have  a  basic  understanding  of  data  processing 
techniques,  but  to  maintain  currency  in  this  rapidly  changing  field. 

The  topics  in  this  section  cover,  in  a  general  way,  the  essentials 
of  data  processing  techniques.    They  cover  the  techniques  currently 
in  use  in  the  field  and  must  be  maintained  with  an  on-going  program 
of  education  because  of  the  speed  with  which  new  developments  are 
taking  place. 

3.  MANAGEMENT  OF  THE  DATA  PROCESSING  FUNCTION 

Good  management  of  the  data  processing  function  is  one  of  the 
key  elements  in  providing  reliable  security  of  computer  operations. 
In  addition  to  being  responsible  for  day-to-day  operations,  these 
managers  must  also  concern  themselves  with  a  myriad  of  other  details 
ranging  from  the  physical  layout  of  their  operations  to  the  reliabil- 
ity of  the  software  used  to  process  data.    The  importance  of  these 
tasks  cannot  be  overemphasized.    The  interrelationship  of  these  tasks 
and  their  contribution  to  the  management  of  on-going  programs  must  be 
understood  by  the  auditor. 

The  topics  in  this  section  introduce  the  "auditor"  to  the  basic 
areas  of  responsibility  associated  with  managing  the  data  processing 
function.    These  topics  also  assist  the  "auditor"  in  placing  the  data 
processing  function  into  appropriate  perspective  within  the  organi- 
zation as  a  whole.    In  this  respect  the  computer  is  the  processor  of 
information  not  the  creator  or  user  of  information  at  least  in  a 
managerial  sense.    Finally,  these  topics  will  help  the  auditor  under- 
stand the  contribution  this  function  makes  in  the  management  of  on- 
going programs. 

4.  SECURITY  OF  THE  DATA  PROCESSING  FUNCTION 

Although  there  are  no  security  techniques  so  foolproof  that  they 
will  prevent  a  determined  and  technically  skilled  intruder  from  pene- 
trating a  computer  system  there  are  certain  measures  that  can  be  taken 
to  discourage  penetration.    These  safeguards  will  vary  from  installa- 
tion to  installation  depending  on  a  number  of  factors  such  as  the 
sensitivity  or  classification  of  the  data,  the  clearance  level  of 
personnel,  and  perimeter  control  to  name  a  few.    An  individual  must 
be  familiar  with  security  techniques  as  well  as  the  sensitivity  of 
the  data  in  a  computer  system  to  be  able  to  make  reliable  evaluations 
of  how  adequately  the  data  is  being  protected.    The  development  of  a 
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remote  access  capability  for  computer  systems  has  added  to  the 
difficulty  of  maintaining  effective  security.    Part  of  an  individuals' 
task  will  be  to  assess  the  adequacy  of  security  for  all  components  of 
a  computer  system. 

The  topics  contained  in  the  outline  are  intended  as  a  starting 
point,  a  listing  of  those  security  measures  that  should  be  used.  This 
listing  is  not  intended  to  be  exhaustive  of  those  measures  only  il- 
lustrative of  them  and  should  be  used  as  a  base  on  which  to  devise 
new  and  more  effective  methods  and  to  build  a  greater  knowledge  of 
this  subject. 

5.  RISK  ANALYSIS  AND  THREAT  ASSESSMENT 

Managers  and  individuals  evaluating  computer  operations  must  be 
able  to  recognize  the  symptoms  of  potential  disaster.    Knowing  the 
probability  of  the  occurrence  of  a  particular  threat  is  a  major  factor 
in  evaluating  the  type  and  nature  of  the  security  procedures  that  will 
be  most  effective  against  it.    Threats  may  come  from  any  direction 
such  as  natural  hazards  (floods  or  fire)  or  personnel  who  may  acciden- 
tally or  deliberately  interfere  with  the  proper  operation  of  a  computer 
system.    In  order  to  be  able  to  evaluate  security  techniques  and 
procedures  an  individual  must  be  able  to  assess  the  extent  of  damage 
that  could  result  from  a  disaster.    Thus,  an  individual  should  have  a 
basic  understanding  of  risk  analysis  techniques  in  order  to  make 
realistic  assessments  of  potential  damage. 

The  list  of  topics  in  this  part  of  the  outline  are  intended  to 
provide  the  basic  understanding  of  the  risk  analysis  techniques  needed 
to  do  this  work  effectively. 

6.  MANAGEMENT  CONCEPTS  AND  PRACTICES 

Most  authorities  view  the  task  of  managing  si ightly differently . 
Perhaps  this  difficulty  is  due  to  the  different  environmental  situations 
in  which  they  have  worked  or  perhaps  it  is  due  to  their  own  tempera- 
mental characteristics  which  have  led  them  to  develop  certain  methods 
of  managing  which,  for  them,  have  proven  to  be  effective. 

Part  of  the  difficulty  also  may  be  due  to  the  fact  that  the  art 
and  science  of  managing  has  been  undergoing  considerable  change  since 
mid-century.    Mathematical  and  statistical  concepts,  the  computer, 
and  the  developing  behavorial  sciences,  to  name  a  few,  have  had  a 
tremendous  impact  on  the  concepts  and  methods  of  managing.    There  are 
no  simple  formulas  or  pat  answers  for  managing.    Managing  is  much  too 
complex  a  task  for  that.    However,  even  though  authorities  view  the 
task  of  managing  differently  they  are  unanimous  in  their  endorsement 
of  the  topics  associated  with  the  task.    Those  topics  have  been  in- 
cluded in  the  panel's  outline  of  the  common  body  of  knowledge  needed 
to  audit  computer  security. 
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7.    AUDITING  CONCEPTS  AND  PRACTICES 


The  techniques  of  auditing  and  the  related  topics  form  the 
foundation  for  conducting  evaluations  of  computer  security.  Auditing, 
per  se,  is  almost  as  old  as  civilization.    It  was  used  in  ancient 
Egypt,  the  Roman  Empire,  and,  of  course,  the  great  mercantile  estab- 
lishments of  the  Middle  Ages.    The  common  areas  of  audit  action 
throughout  its  history  have  been  examining,  verifying  and  reporting. 
Auditing  has  become  a  key  factor  in  controlling  every  kind  of  organi- 
zation and  its  importance  has  only  increased  since  the  advent  of  the 
computer.    For  example.  Jack  Brooks,  Chairman,  Committee  on  Government 
Operations,  House  of  Representatives  recently  stated  that  the  lack  of 
utilization  reviews  was  one  of  the  basic  problems  in  the  Federal 
Government^ . 

Since  the  advent  of  the  computer,  the  potential  threats  to  which 
information  can  be  subjected,  whether  by  accidental  disclosures, 
casual  but  unauthorized  access  or  by  deliberate  attack  have  increased 
tremendously.    Thus,  the  need  to  continually  audit  computer  security 
cannot  be  overemphasized. 

The  topics  included  in  this  section  of  the  common  body  of 
knowledge  are  those  most  commonly  associated  with  the  field  of 
accounting.    They  provide  both  the  auditor  and  the  non-auditor  a 
solid  foundation  in  the  principles  and  practices  of  auditing  an  es- 
sential ingredient  to  the  team  conducting  evaluations  of  computer 
security. 

8.    BASIC  QUALIFICATIONS  NEEDED 
TO  EVALUATE  COMPUTER  SECURITY 

The  qualifications  identified  by  the  panel  represent  those 
experience  factors  an  individual  should  possess  in  addition  to  a  solid 
foundation  in  management,  auditing  concepts  and  practices,  data 
processing,  and  related  telecommunications. 

It  was  the  general  consensus  of  the  panel  that  an  individuals 
basic  education  and  experience  must  be  supplemented  by  approximately 
one  additional  academic  year  or  equivalent  of  education  in  the  subjects 
considered  to  be  the  essential  components  of  the  common  body  of 
knowledge  needed  for  this  work.    This  additional  education  represents 
about  400-500  classroom  hours  of  effort.    For  purposes  of  comparison, 
each  classroom  hour  was  considered  to  be  50  minutes  in  duration.  A 
one  semester-three  unit  college  course  would  meet  three  times  each  week 
for  14-16  weeks.    Such  a  course  would  represent  42-48  classroom  hours 


'Administration  of  Public  Law  89-306  Procurement  of  ADP  Resources 
by  the  Federal  Government,  Thirty-Eighth  Report  by  the  Committee  on 
Government  Operations  together  with  Additional  Views,  House  Report 
No.  94-1746,  October  1,  1976. 
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of  work.  Also,  it  may  take  an  individual  one  to  five  years  of  on-the- 
job  training  or  practical  experience  in  auditing  computer  security  be- 
fore they  become  highly  efficient  and  effective  in  this  work. 

SUMMARY 

Since  the  computer  is  rapidly  becoming  one  of  our  most  useful 
tools  and  the  predictions  on  its  future  use  are  many  and  varied,  it 
becomes  increasingly  important  that  managers  and  other  users  are 
able  to  rely  on  the  products  it  produces.    As  these  individuals 
become  more  dependent  on  its  use  they  will  tend  to  rely  more  heavily 
on  the  information  provided  them  by  individuals  conducting  audits  of 
their  computer  security,  so  that  their  computer  operations  will  become 
an  ally  rather  than  a  nightmare  of  error  and  financial  loss.  For 
these  reasons  the  individuals  conducting  these  audits  must  be  highly 
qualified  and  well  trained.    The  common  body  of  knowledge  outlined 
below  is  intended  to  be  a  basis  for  developing  the  needed  level  of 
expertise. 
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OUTLINE 


COMMON  BODY  OF  KNOWLEDGE 
NEEDED  TO  AUDIT  COMPUTER  SECURITY 


1.  COMPUTER  SYSTEMS,  OPERATIONS,  AND  SOFTWARE 

A.  Theory  of  systems  (as  applied  to  information  systems) 

B.  Theory  of  computers 

C.  Theory  of  data  communications 

2.  DATA  PROCESSING  TECHNIQUES 

A.  Information  structures 

B.  Programming  languages 

C.  Sort  and  search  techniques 

D.  File  creation,  maintenance,  and  interrogation 

E.  Storage  devices 

F.  Data  management  systems 

G.  Integrated  systems 

H.  The  dynamics  of  developing,  modifying,  and  maintaining 
computer  software 

3.  MANAGEMENT  OF  THE  DATA  PROCESSING  FUNCTION 

A.  Organizational  structures 

B.  Personnel  selection,  training,  and  management 

C.  Operating  and  organizational  policies  and  procedures 

D.  Computer  operations 

E.  Analysis,  design,  and  programming  functions 

4.  SECURITY  OF  THE  DATA  PROCESSING  FUNCTION 

A.  The  computer  center 

B.  Remote  sites 

C.  Systems  including  operating,  application,  and  tele- 
communications software 

D.  Policies  and  procedures 

E.  Personnel 

F.  Data  handling 

G.  Recovery  capabilities 

H.  Tests  of  internal  controls 

5.  RISK  ANALYSIS  AND  THREAT  ASSESSMENT 

A.  Physical  facilities 

B.  Remote  sites 

C.  Software 

D.  Information 

6.  MANAGEMENT  CONCEPTS  AND  PRACTICES 

A.  Management  tasks,  responsibilities,  practices,  and  ethics 

B.  Business  administration 

C.  Principles  of  organizational  structures 

D.  Concepts  of  general  management 

E.  Management  of  the  human  resource 
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7.  AUDITING  CONCEPTS  AND  PRACTICES 

A.  Introductory  accounting 

B.  Intermediate  accounting 

C.  Advanced  accounting 

D.  Cost  accounting 

E.  Municipal  and  governmental  accounting 

F.  Auditing 

8.  ADDITIONAL  QUALIFICATIONS  NEEDED  TO  AUDIT  COMPUTER  SECURITY 

Individuals  selected  to  conduct  audits  of  computer 
security,  in  addition  to  the  common  body  of  knowledge 
outlined  above,  should  have  the  following  qualifications: 

1.  Sufficient  experience  to  be  able  to  plan,  direct, 
and  coordinate  audits  of  large  complex  functions, 
activities,  or  programs, 

2.  The  ability  to  assign  tasks  to  individuals  on  the 
team  and  to  identify  the  specific  disciplines  and 
expertise  needed  to  perform  the  work,  and 

3.  The  ability  to  conduct  conferences  and  to  prepare, 
present,  and  process  the  report  describing  the 
results  of  the  work. 
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PART  V:    SECURITY  ADMINISTRATION 


Chairperson: 


Malcolm  Blake  Greenlee 
Citibank 
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Department  of  Health,  Education, 

and  Welfare 


From  left  to  right:    Linwood  M.  Culpepper,  Donald  L.  Eirich,  Malcolm 
Blake  Greenlee,  Thomas  Fitzgerald,  David  L.  Costello,  Wallace  R. 
McPherson,  Jr. 


Note:    Titles  and  addresses  of  attendees  can  be  found  in  Appendix  A. 
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EDITORS'  NOTE 


A  brief  biography  of  the  Session  Chairperson  follows: 

Mr.  Malcolm  Blake  Greenlee  is  an  Assistant  Vice  President  in  the 
Comptroller's  Division  at  Citibank.    His  responsibilities  include  the 
development  of  corporate  policies  and  standards  for  data  center  con- 
struction, operational  risk  analysis,  physical  and  communication  secu- 
rity, and  privacy.    He  is  also  responsible  for  assessing  risk  and  the 
development  and  emplacement  of  procedures  to  offset  new  operational 
risks.    His  career  began  in  research  and  teaching  at  Purdue  University 
in  1556.    He  was  associated  with  Johns  Hopkins  University  from  1957  - 
1968  in  positions  including  Senior  Physicist,  Program  Manager  for  sat- 
ellite navigation  equipment  for  Polaris  submarines,  and  Program  Manager 
at  the  Applied  Physics  Laboratory  for  a  variety  of  systems.    He  served 
on  the  staff  of  the  Mitre  Corporation  and  as  a  faculty  member  at  Ad- 
vanced Management  Research.    Since  joining  the  Citicorp  organization  in 
1969,  he  has  held  positions  as  Program  Manager  responsible  for  all  as- 
pects of  installing  a  world-wide  automated  payments  system  and  Manager 
for  all  technical  activities  of  Citicorp's  subsidiary.  Transaction  Tech- 
nology -  East.    He  received  his  BS  in  Physics  and  Mathematics  from 
Purdue,  with  graduate  studies  in  Physics  at  Purdue  and  Maryland.    He  re- 
ceived his  MBA  in  Finance  and  Administration  from  George  Washington 
University.    He  has  published  several  books  and  holds  several  patents. 


The  charge  given  to  this  session  was: 

SECURITY  ADMINISTRATION:  What  audit  approaches  and  techniques  can 
be  used  in  an  evaluation  of  the  security  administration  function? 

A  security  administration  function  has  been  established  in  a  number  of 
organizations  to  ensure  the  efficiency  and  effectiveness  of  the  physical, 
procedural,  and  technical  controls  within  an    information  processing 
system.    Such  functions  have  been  established  at  various  organizational 
levels  and  assigned    different  responsibilities.    Some  are  staff  and 
others  line  with  either  a  centralized  or  decentralized  concept  being 
employed. 

This  session  is  to  define  the  duties  and  responsibilities  of  such  a 
function  in  a  large  organization  and  its  most  effective  organizational 
structure.    Further,  the  audit  approaches  and  techniques  to  be  used  in 
evaluating  such  a  function  should  be  identified. 


The  following  consensus  report  was  written  and  reviewed  by  the  entire 
group. 
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Security  Administration 
A  Consensus  Report 

David  L.  Costello 
Linwood  M.  Culpepper 
Donald  L.  Eirich 
Thomas  Fitzgerald 
M.  Blake  Greenlee 
Wallace  R.  McPherson,  Jr. 

1.  INTRODUCTION 


1.1  General 

F^ederal  I^nformation  P^rocessing  Standards  (FIPS)  are 
coordinated  and  issued  in  accordance  with  the  provisions 
of  the  Brooks   Act    (PL  89-306)  to  provide  guidance  for 
information  processing  systems  within  U.S.  federal  govern- 
ment (and  related  agencies)  in  areas  such  as 

safeguarding  the  system, 

-  providing  for  continuity  of  operations,  and 

-  safeguarding  the  information  being  processed  by 
the  system. 

Legal  requirements  for  the  handling  of  personal  information 
are  imposed  by  the  Privacy  Act  of  1974.     This  law  may  be  viewed 
as  an  embodiment  of  the  desires  of  U.S.  citizens  to  have  certain 
prudent  measures  put  in  place  to  safeguard  their  implicit  right- 
to-privacy.     Organizations  falling  under  purview  of  the  Act 
tend  to  be  very  large  and  decentralized.     This  paper  describes 
one  method  of  coping  with  compliance  with  these  public  wishes 
expressed  by  law,  implementation  of  a  Security  Administration 
Function.     The  implementation  described  is  based  on  standard 
ADP  auditing  requirements  utilizing  the  technology  base  provided 
by  the  Federal  Information  Processing  Standards. 

Given  a  well  defined  security  administration  function,  the 
audit  of  that  function  becomes  a  standard,  compliance  type  review. 
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1.2    Privacy  Legislation 


1.2.1    The  Privacy  Act  of  1974 


Public  Law  93-579,  known  as  the  Privacy  Act  of  1974,  was 
enacted  into  law  to  protect  the  privacy  of  the  collection  of 
increasing  amounts  of  personal  information.     This  individual 
data  is  being  aggregated  in  the  face  of  increasing  availability 
of  personal  information  made  possible  by  technological  improve- 
ments and  the  data  requirements  of  an  expanding  governmental 
structure.     Agencies  falling  within  the  purview  of  this  statute 
are  required  to  establish  appropriate  administrative,  technical 
and  physical  safeguards.     Agency  rules  for  carrying  out  these 
requirements  are  defined  in  the  Privacy  Act  of  1974  (5  USC  552a) . 
Implementation  of  these  rules  is  being  accomplished  by  many 
agencies/departments  by  adding  management  structure  -  at  each 
organizational  level  at  or  above  the  data  center  user.  The 
structure  performs  the  Security  Administration  function. 

1.2.2    Laws  in  Other  Countries 

The  United  States  is  but  one  of  the  many  countries  that  have 
passed  or  are  considering  public  and/or  private  sector  pri- 
vacy legislation.     In  particular,  legislation  has  passed  in 

o  Sweden 

o    Germany,   (Federal  and  the  State  of  Hesse), 

and  is  pending  in 

o  Norway 

o    Denmark,  and 

o  France. 

Implications  on  systems  design  that  must  be  addressed  be- 
cause of  the  extra-territorial  features  of  these  laws  include 

o    trans-border  information  flow 
o    national  sovereignty  issues 

o    liability  issues  for  interruption  of  information 
flow  in  time  or  in  anticipation  of  war,  etc. 
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1.2.3     International  Privacy  Law  Compatibility 

The  Council  of  Europe  (with  U.S.  State  Department  and  the 
Office  of  Telecommunications  Policy)  has  begun  an  effort  to 
harmonize  requirements  of  conflicting  laws.     It  is  hoped  that 
this  harmonization  by  treaty  may  occur  in  the  not-too-distant 
future  to  alleviate  the  systems  implications  in  the  present 
(and  pending)  environment. 

While  the  security  administration  function  is  implicit 
in  many  foreign  laws  (as  in  "1974"),  the  German  law  explicitly 
requires  that  a  "Federal  agent  for  the  Safeguarding  of  Data"  be 
appointed  and  provided  staff  to  organize,  manage,  carry  out  and 
report  on  security  administration.     Private  sector  firms  must 
have  a  similar  structure.     Because  of  the  similar  requirements 
of  the  German  Law  and  the  Privacy  Act  of  1974  and  the  clarity 
of  definition  of  the  function,  duties,  etc,  of  the  "agent" 
within  that  law,  a  precis  of  the  duties  of  the  "agent"  is  attached. 

1.3    Organization  of  this  Report 

This  report  is  organized  in  three  chapters  and  one 
appendix. 

Following  this  Introduction  chapter.  Chapter  2  (Security  Adminis- 
tration) discusses  the  planning,  management  control,  ADP  security 
duties  and  functions  of  the  security  administrator.     Chapter  3 
(Auditing  the  Security  Administration  Function)  recommends  the  organi- 
zational requirements  for  the  audit  function  and  the  audit  approach 
to  be  used. 

The  appendix  contains  a  precis  of  some  pertinent  require- 
ments of  the  Federal  German  privacy  law. 

2.     SECURITY  ADMINISTRATION  PROGRAM 


2.1  Introduction 

The  concerns  expressed  in  Chapter  I  have  given  rise  to  the 
need  for  the  organization  function  of  Security  Administration  in 
Federal  Agencies  (This  may  be  relatively  new  for  many  Agencies). 
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While  Security  Administration  includes  the  traditional  concerns 
for  data  integrity  and  protection  of  the  organization's  informa- 
tion resources  from  modification,  loss  or  destruction,  it  must 
also  concern  itself  with  safeguarding  the  information  from  dis- 
closure or  improper  use.     Thus,  Security  Administration  should 
constitute  an  integrated  program  for  protection  of  data  in  the 
organization's  custody.     We  are  here  concerned  with  the  prin- 
ciples of  Security  Administration  applicable  to  ADP  systems. 
In  general,  a  separate  Security  Administration  function  may  be 
practical  only  in  large  organizations.     In  smaller  organiza- 
tions, the  function  may  be  combined  with  other  functions  and 
j  obs . 

The  session  panel  members  believe  that  the  responsibility 
for  safeguarding  the  organization's  data  and  information 
resources  should  be  the  personal  responsibility  of  individuals 
having  physical  custody  and  accountability  for  it.  Moreover, 
the  Privacy  Act  of  1974  imposes  a  personal  liability  on  any 
officer  and  employee,  with  criminal  penalties,  for  improper 
and  wilful  disclosure.     Thus,  we  believe  that  security  of 
information  is  properly  a  line  responsibility,  extending  up 
and  down  the  chain  of  command.     To  segregate  this  responsi- 
bility from  other  custodial,  processing  and  supervisory 
responsibilities,  and  place  it  solely  upon  a  separate  security 
administration  entity,  seems  patently  impractical  except 
perhaps  in  unusual  circumstances. 

It  follows  then,  that  Security  Administration!  should 
be  a  staff  function  (independent  of  the  DP  line  organization)  sup- 
porting management  at  appropriate  organizational  levels  and 
the  central  office.     Security  Administration  should  be 
responsible  for  developing  overall  policy  and  monitoring,  on 
a  continuing  basis,  the  overall  effectiveness  of  the  security 
program. 

2.2      Planning  by  Management 

Planning  for  security  administration  is  carried  out  at  three 
levels  within  the  organization.     At  the  highest  level,  broad  policy 
statements  are  developed  which  address  such  issues  as: 


Note:  Viewed  in  this  context,  'Security  Administration'  as 
used  throughout  this  paper  is  probably  a  misnomer  and  might 
better  be  designated  Security  Program  Administration." 
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o    What  are  the  steps  which  must  be  taken  prior  to  the 

approval  of  an  ADP  installation? 
o    How  are  exceptions  to  established  policy  granted? 
o    How  is  compliance  with  established  policy  determined 

initially  and  during  the  life  of  the  installation? 
o    How  is  policy  maintained  and  updated  as  a  result  of 

operational  experience? 

At  an  intermediate  level  in  the  organization,  more  detailed 
instructions  which  implement  the  policy  are  developed.  These 
instructions  address  such  issues  as: 

o    What  factors  must  be  considered  in  performing  the  risk 
analysis  for  an  ADP  system?    Of  these  factors,  which 
are  to  be  taken  as  input  and  therefore  immutable  and 
which  can  be  taken  as  output? 

o    What  are  the  checkpoints  in  the  implementation  of  a 

system  and  what  documentation  must  be  completed  at  each 
checkpoint? 

o    What  types  of  reports  are  required,  who  prepares  the 
reports,  and  who  receives  the  reports.     Reports  may  be 
required  for  various  levels  of  security  breaches.  For 
example,  each  level  of  breach  may  require  a  report 
to  a  different  level  within  the  organization. 

o    Who  within  the  organization  is  responsible  for  each 
aspect  of  security?    These  aspects  include  personnel 
screening,  audit  trails  analysis,  security  breach 
reporting,  etc. 

At  a  lower  level  within  the  organization,  the  actual  implemen- 
tation of  instructions  is  accomplished.     At  this  level,  the  func- 
tions performed  include  preparation  of: 

o    a  schedule  of • implementation  of  instruction,  and 

o    estimates  of  the  resources  required  for  implementation. 

2.3      Management  Control 

Management  control  consists  of  the  exercise  of  those  controls 
which  are  traditionally  necessary  to  ensure  that  the  security  objec- 
tives of  the  organization  are  achieved,  including: 
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Policy  -  the  statements  of  management  objectives  for: 


o    the  protection  of  organization  interests, 
o    organizational  data, 
o    ADP  resources,  and 

the  prevention  of  abuse  of  these  resources,  in  an  efficient  and 
cost-effective  manner.     They  should  provide  clear  direction  in 
such  matters  as: 

o    what  information  is  to  be  protected, 

o    the  levels  of  protection  to  be  accorded, 

o    what  officials  have  authority  to  disclose  or  release 

information  and  to  whom,  and 
o    disciplinary  measures  for  violations,  etc. 

Such  policy  should  generally  be  formulated  at  organiza- 
tional levels  above  the  Security  Administration  function  or  at 
the  least,  with  full  participation  of  top  management.  The 
policies  will  comprise  the  basis  for  the  security  program. 

Procedures  -  descriptions  of  the  processes  and  the  instruc- 
tions for  carrying  out  management  objectives.     They  must  be  suf- 
ficiently detailed  for  implementation,  at  subordinate  supervisory 
levels,  of  those  administrative,  physical  and  technical  security 
measures  and  controls  described  in  the  succeeding  section.  They 
should  include  the  nature,  timing  and  recipients  of  reporting  and/ 
or  exceptions  thereto.     Procedures  should  not  be  limited  to  the 
execution  of  the  ADP  function,  but  should  extend  to  the  security  of 
data  and  ADP  resources  employed  by  organizational  users  of  these 
resources.     Such  procedures  should  be  disseminated  only  after 
review  and  concurrence  by  the  Security  Administration  staff. 

Practices  -  such  other  activities  that  are  dictated  by 
traditional  management  principles  including: 

o    adequate  supervisory  review  or  control, 
o    employee  activity  monitoring, 
o    quality  control, 

o    investigation  of  known  or  suspected  violations  of 

the  system,  and 
o    initiation  and  enforcement  of  disciplinary  actions. 
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2.4    ADP  Security 

2.4.1  Administrative  Security 

The  security  administration  function  must  include  the  res- 
ponsibility for  development  and  maintainance  of  administrative 
safeguard  standards,  including: 

o    Security  Implementation  Plans  based  on  analyses  of  the 
existing  physical,  technical,  and  administrative  safe- 
guards, and  consideration  of  determinations  by  system 
managers  of 

the  vulnerabilities  of  their  data  and  resources, 
and 

the  protection  necessary  to  safeguard  against 
these  vulnerabilities. 

Plans  must  detail  the  actions,  resources  and  scheduling 
necessary  to  implement  necessary  additional  safeguards. 

o    Contingency  Plans  that  show  the  action  to  be  taken  when- 
ever an  error,  unauthorized  disclosure  or  violation  of 
privacy  safeguard  procedures  is  detected.     The  plan  must 
cover  notification  and  where  appropriate,  recovery  or 
corrective  action. 

o    Disaster  -  Emergency  Processing  Plans  which  include  the 
capability  of  protecting  and  recovering  all  personal  data 
for  which  the  facility  has  a  safeguard  and  back-up  res- 
ponsibility.    The  plan  must  provide  for  continued  com- 
pliance with  all  security  safeguards. 

o    Facility  Security  Profile  Documentation  which  documents 
in  a  single  file: 

-  procedures  to  be  followed  by  all  personnel  and 
organizations  working  for  or  interfacing  with  the 
facility, 

-  location  and  format  of  all  security  records  such 
as  logs  and  audit  trails, 

-  results  of  all  internal  and  external  security 
inspections , 
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results  of  any  risk  analysis  performed, 
copies  of  the  facility  security  implementation 
plan,  and 

copies  of  any  contingency  backup  and  disaster  plans, 
o    Authorization  Control  Lists  which  include 

lists  of  persons  authorized  to  enter  the  facility, 

-  authorized  terminal  users,  and 

-  authorized  terminals. 

All  lists  must  be  maintained  current. 

o    Programming  Modifications,  Testing  And  Validation 
Controls  which  require: 

restriction  of  data  and  system  specifications  to 
only  those  individuals  who  have  a  "need-to-know", 
procedures  to  control  modifications  which  require 
testing  before  any  program  changes  become  opera- 
tional, 

testing  of  new  systems  or  modifications  to  systems 
using  simulated  test  data, 

-  validation  of  functional  adequacy  and  reliability 
of  a  system  before  the  system  is  put  into  opera- 
tion, and 

modular  separation  of  the  duties  of  analysts  and 
programmers  (when  the  staff  size  permits). 

o    Personnel  Management  Rules  to 

establish  authorities  and  responsibilities, 

-  develop  security  awareness  and  other  employee 
involvement  programs  for  the  purpose  of 
creating  a  positive  operational  atmosphere,  and 

-  determine  that  adequate  evaluation  of  potential 
staff  members  is  performed. 

The  basic  role  of  administrative  safeguards  is  to  establish 
those  activities  which  are  functions  of  human  authorities,  judge- 
ment and  decision  processes. 
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2.^.2  Physical  Security  Administration 

2.4.2.1    Physical  Access 

Controlling  access  to  the  data  processing  facility  or  Its 
Individual  component  resources  Is  a  basic  step  In  providing 
security.     It  should,  however,  be  considered  as  only  the  first 
level  of  security  and  represents  the  base  upon  which  the 
other  levels/forms  of  security  build.     The  following  con- 
siderations are  necessary  when  creating  security  procedures  to 
restrict  personal  access. 

o    Areas  to  be  restricted:  may  Include: 

-  the  overall  building, 

-  data  processing  center (s), 

-  all  ancillary  equipment  and  facilities  (key  punch, 
key  tape,  printers,  bursters,  etc.), 

-  remote  job-Input  or  output  devices, 

-  remote  terminals, 

-  auxllllary  power,  fuel  or  water  storage  areas, 

-  communication  cable  housing  or  concentrator 
locations,  etc. 

o    Multiple  levels  of  restriction:     A  person  who  has  a 
valid  need  to  access  one  area  of  the  data  pro- 
cessing facility  will  not  necessarily  need  access 
to  all  or  other  areas  of  this  facility.     When  pos- 
sible, access  to  the  Individual  areas  should  be 
separated  and  controlled  Individually. 

o    Method  of  access  restriction:     Choices  of  how  access 
Is  restricted  may  Include: 

-  locked  doors  (key  or  combination  operated) , 

-  guarded  doors  and  personal  Identification, 

-  guarded  doors  with  badge  or  pass  Identifica- 
tion, 

-  electrically  locked  doors  activated  by  the 
Individual  using  a  number  code, 

-  electrically  locked  doors  activated  by 
magnetically  encoded  pass  or  badge. 
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-  electrically  locked  doors  activated  upon  checking 
personal  identification  (signature,  palm  or  finger 
print  (not  readily  feasible) ,  or 

-  combinations  of  two  or  more  of  the  above. 

When  determining  an  access  control  method,  it  will  also  be 
necessary  to  consider  the  manner  in  which  these  devices  will 
function  from  inside  the  controlled  area — particularly  in 
emergency  situations.     Devices  must  permit  free  and  ready  exit 
in  time  of  emergency  for  personnel  safety  (as  required  by 
applicable  fire/life  safety  laws  and  regulations). 

2.4.2.2      Disaster  Protection 

While  the  data  processing  resources  should  be  protected 
against  the  physical  damage/loss  of  equipment,  provision  for 
continuity  of  operations  must  also  be  given  priority  attention. 
Potential  occurences  should  be  ranked  by  likelihood,  and 
reasonable  preventative  measures  should  be  instituted.  Some 
of  the  more  likely  occurences  are:^ 

o    loss  of  power  (total  or  shortage), 

o    loss  of  water  (for  some  equipment,  air  conditioning), 
o  fire, 

o    flood  or  water  damage  (natural,  broken  piping 
inside  or  outside  facility,  or  fire  activated, 
o    explosion,  etc. 

Various  methods  can  be  employed  to  minimize  identified 
possibilities.     Some  alternatives  available  are: 

o    alternate  public  power  routing, 

o    private  generators  (with  or  without  electrically 

activated  uninterruptable  features), 
o    private  water  storage  facility  or  acquisition 

plans , 

o    appropriately  rated  fire  resistant  materials, 
o    products  of  combustion  or  heat  activated  fire 
suppression/systems  (Halon,  sprinklers),  etc. 


See  also  NBS  FIPS  PUB  31,     Guidelines  for  Automatic  Data 
Processing,  Physical  Security  and  Risk  Management,  (June, 
1974),  SD  Catalog  Number  C13.52:31. 
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2.4.2.3      Back-up  Facility 


In  the  event  of  a  total  or  significant  partial  loss  of 
the  processing  capability  of  the  ADP  facility,  it  will  be 
necessary  to  activate  either  a  contingency  plan  or  the 
emergency  processing  plan  (see  Section  2.4.1).  Physical 
security  measures  must  be  provided  for  this  back-up  faci- 
lity as  well  as  during  the  movement  of  necessary  forms, 
data  files,  output,  personnel,  etc.  to/from  the  back-up 
site. 

2.4.2.4  Storage  Libraries 

Adequate  physical  storage  areas  must  be  set  aside  for 
the  protection  of 

o    tape,  disk,  card  files/records, 

o    program  documentation  including  operator  run  documenta- 
tion and  programmer /analyst  design  and  maintenance  docu- 
mentation, 

o    various  administrative  security  control  records/plans 
including 

-  authorization  lists, 

-  security  profile/level  documentation  and, 

-  emergency  back-up/processing  plans. 

These  areas  must  be  appropriately  structured  to  preclude 
access  by  unauthorized  personnel  and  also  to  protect  against 
disaster.     These  libraries  should  generally  receive  the 
highest  degree  of  both  access  and  disaster  security  in  com- 
parison to  other  ADP  resources.     Since  many  of  the  data  files 
will  be  back-up  at  off-site  locations,  the  off-site  facility 
should  receive  the  same  or  comparable  level  of  security  protec- 
tion.    Appropriate  precautions  must  be  taken  during  the  move- 
ment of  these  files  between  sites. 

2.4.2.5  Data  Handling  and  Disposal 

Certain  physical  security  techniques  may  be  appropriate 
in  the  handling  of  data  within  the  ADP  facility.     If  multiple 
security  levels  are  employed  within  the  facility,  handling  of 
this  information  should  be  either  restricted  to  those  areas 
necessary,  or  methods  must  be  instituted  to  prevent  observa- 
tion as  the  information  is  moved  (such  as  by  means  of  sealed/ 
locked  containers/carriers/ trucks) . 
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Consideration  should  be  given  to  readily  Identifying, 
in  some  physical  manner,  data  containing  restricted  or  per- 
sonal information.     This  could  be  done  by  means  of  visible 
labeling,  color  coding  of  labels  or  reels,  physically  sepa- 
rating storage  locations  of  such  files,  etc.     However,  it 
should  also  be  remembered  that  such  techniques  also  readily 
identify  these  files  for  improper  access  attempts. 

It  is  also  necessary  that  appropriate  disposal  techniques 
be  devised  for  outdated  files,  input  and/or  output.     When  infor- 
mation is  no  longer  retained,  the  file  should  be  erased  or  des- 
troyed such  as  by  degausing  or  use  of  write-over  procedures 
before  re-use.     Computer  generated  scrap  material  such  as  forms 
used  when  aligning  printers  or  when  jobs  are  redone  should  be 
handled  in  the  same  manner  as  outdated  input  and  output.  Nor- 
mal means  of  disposal  include  shredding,  incinerating  (may  pro- 
duce environmental  problems),  compaction  or  mulching  under  esta- 
blished control  procedures. 

2.4.3    Technical  Security 

o    Security  System 

The  security  officer  is  responsible  for  the  maintenance 
of  the  security  system  programs  and  all  files  associated 
with  it.     Requests  for  changes  in  user  profiles  must  be 
originated  by  area  management  with  appropriate  manage- 
ment and  security  approvals.     (Changes  to  the  area  security 
administrator  profiles  are  made  only  by  the  security 
administrator. ) 

o    Data  and  Files 

The  security  administrator  is  responsible  for  the  pro- 
gram to  protect  the  contents  and  physical  safety  of  all 
files.     Using  the  security  system  he  must  ensure  that  the 
system  is  adequate  to  protect  all  data. 

o    Program  Libraries 

The  Security  Administrator  is  responsible  for  ensuring 
the  accuracy  of  program  libraries.     His  functions  in  this 
regard  include: 
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-  ensuring  that  an  access  control  program  to  restrict 
access  to  all  programs  and  any  test  files  under  his 
control  is  operational 

-  providing  copies  of  programs  and  appropriate  test 
data  only  to  authorized  personnel  upon  receipt  of 
written  requests  from  appropriate  management  personnel, 
providing  a  method  for  applying  program  changes  and 
ensuring  a  reasonable  period  of  parallel  testing,  and 

-  providing  appropriate  backup  facilities  for  program 
libraries  and  data  files  to  ensure  continuity  of 
processing. 

o    Operating  System 

Line  ADP  management  is  responsible  for  the  maintenance  of 
the  operating  system,  and  should  apply  "fixes"  generated 
by  hardware  vendors  with  the  approval  of  the  system  pro- 
grammers.    Included  in  this  is  the  responsibility  for  mainte- 
nance and  testing  of  changes  to  the  system.  Responsibility 
for  the  change  of  security  control  security  and  the  stability 
of  the  operating  system  rests  with  the  Security  Admini- 
strator. 

o  Teleprocessing 

The  security  administrator  is  responsible  for: 

-  user  tables  and  teleprocessing  security 
(including  the  maintenance  of  security  modules 
within  the  TP  system) ,  and 

backup  and  recovery  of  TP  systems  (including 
backup  features  (e.g.,  dial  up),  line  control 
and  investigation  of  security  violations) . 

o  Encryption 

The  security  administrator  is  responsible  for: 

-  maintenance  of  encryption  algorithms  where  appro- 
priate, and 

-  control  the  generation,  distribution  and  use  of  keys  for 
use  with  the  algorithm. 


ii 
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2.4.4  Training 


There  are  two  aspects  to  training  for  the  security  function 

o    training  for  those  who  implement,  maintain,  and  operate  the 

system,  and 
o    training  for  those  who  use  the  system. 

The  first  group  should  have  a  more  formal  training  curriculum 
coupled  with  an  established  career  path  in  ADP  security  adminis- 
tration.    A  variety  of  subjects  ranging  from  technical  aspects  of 
design  and  use  of  ADP  hardware  and  software  to  the  provisions  of 
the  Privacy  Act  should  be  taught  on  a  regular  basis. 

The  users  of  the  system  should  be  given  training  on  the 
the  consequences  of  a  security  violation,  etc.     These  users 
should  be  examined  periodically  to  ensure  that  they  are  pro- 
perly trained. 

2.4.5    A  Suggested  Security  System  for  an  On-line  System  - 
An  Example 

The  security  system  desired  for  large  scale  on-line  systems 
must  be  comprehensive  enough  to  act  as  an  effective  buffer  between 
the  terminals  and  the  application  programs  and  files.     The  level 
of  sophistication  can  be  reduced  as  system  size  and  complexity 
are  reduced.     However,  some  automated  system  should  exist.  The 
suggested  system  is  comprised  of  three  security  files  as 
follows: 

o    Terminal  file 

This  file  contains  all  necessary  information  regarding 
current  status  of  the  terminal,  including: 

-  Terminal  ID  -  a  unique  identifier  synonymous  with 
the  specific  terminal.     This  identifier  is  a  hardware 
feature  of  each  terminal  and  is  contained  in  every 
message  sent  by  the  terminal. 

-  User  ID  -  a  unique  identifier  which  is  inserted  in 
this  file  after  a  successful  log-on.     This  field  is 
appended  to  the  transaction  message  prior  to  logging 
the  transaction.     This  assures  that  each  message 
contains  the  identification  of  the  sending  terminal, 
and  the  person  sending  the  message. 

Terminal  status  -  this  field  contains  the  status  of 
the  terminal. 
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— dormant  -  terminal  has  not  as  yet  logged  on 

— log-on  in  process  -  log-on  message  received  but 
password  not  verified 

— active  -  log-on  successfully  completed  and  user 
ID  field  updated 

— violation  -  security  violation  attempt  discovered. 
Terminal  is  logged  off  until  investigation  is  com- 
pleted. 

Violation  counter  -  this  field  contains  the  number  of 
unsuccessful  (invalid)  attempts  to  enter  either  an 
erroneous  password  or  an  erroneous  transaction  type. 
If  this  counter  equals  some  preset  number,  say  3, 
the  terminal  status  is  set  to  "violation." 

-  Time  of  last  transaction  -  if  the  terminal  does  not 
require  log-on  for  each  transaction  this  field  con- 
tains the  time  of  last  transaction  for  an  "idle" 
check.     If  the  elapsed  time  between  messages  is 
greater  than  a  preset  idle  time,  the  terminal 
status  is  set  to  dormant  and  a  log-on  is  required 
to  re- initialize  the  terminal. 

o    User  profile 

This  file  contains  all  information  pertaining  to  a  ter- 
minal operator,  including: 

-  User  ID  which  is  a  unique  identifier  synonjnnous  with 
a  specific  individual.     This  field  is  most  commonly 
the  employee  number  of  the  terminal  operator. 

-  Password  which  is  a  unique  code  which  is  entered  by 
the  terminal  operator  which  identifies  the  terminal 
operator  to  the  system.     This  data  is  entered  by 
the  operator  in  a  'print  inhibit'  mode.  (This 
means  the  password  does  not  display  on  the  terminal.) 
After  validation,  the  terminal  status  is  set  to 
"active."    Note  that  there  may  be  more  than  one  level 
of  password  control. 

-  Transaction  codes  are  a  set  of  codes  which  identify 
those  transactions  and  application  module  names  which 
the  terminal  operator  is  cleared  to  perform.  After 

a  successful  log-on,  the  security  system  examines 
these  fields  to  determine  if  a  specific  transaction 
code  is  authorized.     Upon  a  successful  match  the 
application  program  module  is  called  and  control 
passes  to  the  application  module.     If  a  successful 
match  is  not  found  the  violation  counter  is  incre- 
mented by  one  and  the  transaction  is  rejected. 
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o     Transaction  file 


In  more  complex  systems  the  transaction  file  can  be  used 
in  conjunction  with  the  user  profile  as  described  below: 

-  Transaction  ID  is  a  unique  code  used  as  the  key  for 
this  file.     It  is  entered  by  the  terminal  operator. 

-  Sub-code  is  a  field  that  can  be  used  further  to 
restrict  access  to  particular  data  files,  based  on 
the  format,  within  the  file.     If  the  file  is 
broken  into  smaller  units  this  field  can  indicate 
which  of  the  units  can  be  accessed  by  a  particular 
terminal  and/or  operator. 

-  File  ID  is  a  field  which  contains  the  identification 
of  the  master  file  and  the  specific  functions  which 
may  be  performed  by  specific  transaction  types 
against  the  file. 

o    Audit  Trails 

Generally,  audit  trails  should  be  employed  so  that 
Security  Administration  can  monitor  data  and  the  system 
security  features  regulating  data  integrity.     They  can 
be  designed  to  provide  a  variety  of  features  to  meet 
unique  requirements  for  the  level  of  security  determined 
to  be  appropriate  and  reasonable  for  the  perceived  threats 
in  a  particular  organization  or  activity.     In  general,  they 
should  be  designed  to  record  who  had  access  to  what  data. 
Dependent  upon  the  level  of  detail  desired,  they  can 
identify  such  things  as  the  file,  the  record  or  even 
the  data  element  accessed  and  what  transactions  were 
performed. 

The  function  of  the  Security  System  is  to  act  as  a  buffer, 
reduce  the  probability  of  an  accidental  violation  and  raise 
the  level  of  expertise  needed  to  commit  a  deliberate  viola- 
tion.    The  system  relies  upon  a  designated  security  officer 
in  each  area.     All  violations  are  logged  to  a  violations  log 
which  must  be  reviewed  by  a  security  officer  daily  and  on 
a  special  log  for  review  by  the  security  administrator.  This 
officer  should  also  have  an  on-line  hard  copy  terminal  which 
notifies  him,  immediately,  of  each  particular  multiple  violation. 
He  should  then  be  required  to  visit  the  terminal  identified  and 
determine  the  reason  for  the  violation.     The  officer  must  reset 
the  terminal  using  his  special  security  code  to  permit  the  termi- 
nal to  function  again.     In  addition  he  should  be  required  to 
submit  a  report  concerning  the  violation  to  the  individual  res- 
ponsible for  security  administration. 
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3.     AUDITING  THE  SECURITY  ADMINISTRATION  FUNCTION 


3.1  Organizational  Requirements 

The  following  two  organization  considerations  are  neces- 
sary when  establishing  a  program  to  audit  the  Security  Administra 
tion  function. 

o    The  Audit  function  should  be  independent  of  the  Security 
Administration  function. 

o    The  Audit  function  may  be  distributed  but  staff  audit 
members  must  report  either  directly  to  the  agency  head 
or  through  the  head  of  audit  to  the  agency  head. 

3.2  The  Audit  Process 

The  audit  of  the  Security  Administration  function  is 
simply  a  compliance  audit.     The  auditor's  task  is  to  ensure 
that  the  stated  policies  are  being  followed  and  independently 
to  report  his  opinion. 

The  auditor  may  find  varying  standards  and  procedures 
within  the  organization  due  to  differences  in  size,  processing 
environment,  delegation  of  responsibilities,  etc.     Because  of 
this,  the  auditor  must  construct  or  align/extract  an  audit 
program  which  is  appropriate  for  accomplishing  the  corresponding 
Security  Administration  function.     At  all  levels,  the  audit 
program  should  accomplish  the  following,  independently  of  the 
Security  Administration  function. 

o    The  auditor  should  appraise  the  policies  and  standards 
initiated  in  establishing  the  Security  Administration 
function.     The  policies  and  standards  should  be: 

-  comprehensive, 

-  documented, 

-  known  and  understood,  and 

-  complied  with. 

o    The  audit  program  should  evaluate  the  degree  of  compliance 
with  established  control  procedures  and  review  and  appraise 
new  procedures  being  contemplated  using  generally  accepted 
auditing  standards  and  techniques. 

o    The  auditor  should  independently  verify  other  key  control 
points/procedures  within  the  Security  Administration  func- 
tion. 

o    The  auditor  should  identify  any  need  for  added  controls 
which  would  make  the  Security  Administration  function 
more  effective. 
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o    The  auditor  must  report  findings  and  opinions  to  designated 
management . 

The  specific  procedures  and  controls  to  be  reviewed  by 
Auditing  will  result  from  procedures  adopted  such  as  those 
suggested  by  Section  2.0  and  the  specific  delegation  of  res- 
ponsibility. 
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APPENDIX 


SOME  FEATURES  OF  THE  FEDERAL  GERMAN  PRIVACY  LAW 


1.     PUBLIC  SECTOR  DATA  SECURITY  ADMINISTRATION- 
ORGANIZATION 

1.1  The  Office  of  the  Federal  Agent 

A  Federal  agent  must  be  appointed  for  the  safeguarding  of 
data.     The  agent 

o    has  a  term  of  office  of  five  years, 

o    is  an  independent  office  reporting  to  highest  level  of 
government,  installed  at  the  office  of  the  Federal 
Minister  of  the  Interior  and  under  his  service  super- 
visory authority, 

o    has  staff  and  support,  and 

o    has  his  legal  status  precisely  defined. 

1.2  Duties  of  the  Federal  Agent 

The  duties  of  the  Federal  Agent  include 

o  verifying  compliance  with  law, 

o  making  recommendations, 

o  issuing  reports, 

o  requesting/demanding  aid  from  other  agencies, 

o  having  24  hour  register  of  data  banks  storing  personal 

data  (public  record) ,  and 

o  processing/hearing  appeals. 

2.     PRIVATE  SECTOR  DATA  SECURITY  ADMINISTRATION 

2.1    Requirements  for  Corporate/Association  Data  Security  Agents 

A  data  security  agent  must  be  appointed  by  any  person/cor- 
poration/association  "who  processes  personal  data  automatically 
and  thereby  as  a  rule  employs  at  least  five  persons  on  a  per- 
manent basis." 

Requirements  for  the  agent  include: 

o    must  be  appointed  in  writing, 
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o    must  be  competent  to  fulfill  his  duties, 
o    may  not  be  put  to  disadvantage  because  of  accomplishing 
his  duties, 

o    is  not  subject  to  outside  direction,  and 
o    may  appoint /employ  supporting  staff. 

2.2    Duties  of  the  Corporate/Association  Data  Security  Agent 

Duties  of  the  Data  Security  Agent  include: 

o    assuring  compliance  with  the  law, 

o    seeking  assistance  of  governmental  supervisory 

authorities  when  needed  and  without  need  for 

corporate/business  approval, 
o    keeping  records  on  the 

nature  of  stored  data, 
its  purpose, 

persons  requiring  access,  and 

the  nature  of  the  ADP  equipment  in  use, 

o    supervising  "proper"  application  of  the  programs  processing 
personal  data, 

o     training  of  other  employees  as  to  their  responsibilities 

under  the  law,  and 
o    acting  as  a  consultant  to  persons  processing  personal  data. 

3.     CONTROLS  REQUIRED  TO  SAFEGUARD  DATA 

Controls  specifically  required  by  the  law  include: 

o    Access  Control 

~    prohibit  unauthorized  access  to  the  installation 
(equipment),  and 

limit  access  to  data  to  those  having  a  need  to  know 

o    Storage  Control 

prohibit 

unauthorized  input  to  storage, 
acquisition  of  data  from  storage 
-    alteration/cancellation  of  stored  data 
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o    Use  Control 


prevent  use  of  the  data  system  by  unauthorized 
persons  (includes  remote  access  use  control) 

o    Transmittal  Control 

guarantee  that  only  authorized  recipients  may  be 
sent  personal  information  via  automated  installa- 
tions (authentication) 

o    Input  Control 

Maintain  the  capability  to  ascertain 

-  what  personal  data, 
at  what  time,  and 

-  by  whom  was  entered  in  the  system. 

o    Supervisory  Control 

-  Supervision  of  instruction:  authorization  to  process 
personal  data 

Supervision  of  transmission  of  personal  data  so 

that  it  cannot  be 

— read 

— altered,  or 

— cancelled  without  supervision 

Supervision  of  the  organization/internal  structures 
or  boards  of  the  company  to  assure  that  data  is  pro- 
perly safeguarded. 
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PART  VI:    AUDIT  CONSIDERATIONS  IN  VARIOUS  SYSTEM  ENVIRONMENTS 


Chairperson:    Carl  Hammer 
Sperry  UN I  VAC 

Participants : 


Sheila  Brand,  Recorder 

Social  Security  Administration 
P.  J.  Corum 

Bank  of  Montreal 
Ike  Dent 

Credit  Bureau  Inc.  of  Georgia 
Peter  D.  Gross 

Computer  Sciences  Corporation 
Thomas  L.  Hamilton 

Eastman  Kodak  Company 


James  F.  Morgan 

GE  Information  Service 
Gerald  J.  Popek 

University  of  California,  L.  A. 
Stephen  T.  Walker 

Defense  Advanced 

Research  Project  Agency 
Ronald  L.  Winkler 

Sutherland,  Asbill  &  Brennan 


From  left  to  right:    Gerald  J.  Popek,  Peter  D.  Gross,  Carl  Hammer, 
Ronald  L.  Winkler,  Ike  Dent,  Sheila  Brand,  Thomas  L.  Hamilton,  James 
F.  Morgan,  Stephen  T.  Walker,  (P.  J.  Corum,  absent). 


Note:    Titles  and  addresses  of  attendees  can  be  found  in  Appendix  A. 
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EDITORS'  NOTE 

A  brief  biography  of  the  Session  Chairperson  follows: 


Dr.  Carl  Hammer  is  Director,  Computer  Sciences,  at  Sperry  Univac 
as  well  as  Adjunct  Professor  at  the  American  University  and  a  Vis- 
iting Professor  at  the  Industrial  College  of  the  Armed  Forces,  both  in 
Washington    DC.    His  previous  professional  affiliation  included  respon- 
sibility for  the  initial  design  of  the  Minute  Man  Communications  Sys- 
tem for  Radio  Corporation  of  America,  and  positions  as  Director  of  the 
Univac  European  Computer  Center  at  Frankfurt  am  Main  in  Germany  , 
Senior  Staff  Engineer  in  the  Computer  Department  of  the  Franklin  Insti- 
tute in  Philadelphia,  and  teacher  at  Columbia  University  and  Hunter 
College  in  New  York  City.    He  is  Director  of  the  American  Federation 
of  Information  Processing  Societies  (AFIPS),  was  Science  and  Technolo- 
gy Program  Chairman  for  their  first  National  Computer  Conference  (NCC) 
in  1973,  and  Chairman  of  the  entire  1976  NCC.    He  is  a  past  Chairman 
of  the  Washington  Chapter  of  the  Association  of  Computing  Machinery 
(ACM)  and  a  Past  President  of  the  American  Society  for  Cybernetics.  By 
appointment  of  the  Executive  Office  of  the  President,  he  is  a  member 
of  the  National  Defense  Executive  Reserve.    He  is  also  a  member  of  the 
New  York  Academy  of  Sciences,  AAAS,  IEEE,  Research  Society  of  America, 
and  the  Association  of  Computer  Programmers  and  Analysts.    Born  in 
Chicago,  IL,  he  received  his  degrees  in  Mathematical  Statistics  from 
the  University  of  Munich  (Diploma  and  Ph.D.). 

The  charge  given  to  this  session  was: 


AUDIT  CONSIDERATIONS  IN  VARIOUS  SYSTEM  ENVIRONMENTS:    What  are  the 
considerations  to  be  given  to  the  audit  of  computer  security  in 
various  system  environments,  such  as  (a)  distributed  processing, 
(b)  dedicated  systems,  (c)  time-sharing,  (d)  multi-processing, 
(e)  mini /micro  computers,  etc. 

Computer  security  is  generally  considered  a  function  of  the  environment 
in  which  the  system  operates.    A  dedicated  system  operating  in  a  batch 
mode  within  a  benign  environment  has  altogether  different  security  re- 
quirements from  a  shared  automatic  resource  balancing  computer  network. 

This  session  will  address  the  various  system  environments  and  identify 
the  major  aspects  of  each  that  the  auditor  must  consider  in  conducting 
an  evaluation  of  computer  security. 


The  consensus  report  that  follows  was  developed,  written  and  reviewed 
by  the  entire  membership  of  this  session. 
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1.  INTRODUCTION 


During  the  two  months  preceding  the  Workshop,  working  papers  and 
position  statements  were  solicited  and  received.    Relevant  literature 
references  were  collected  and  disseminated.    This  documentation  was 
reviewed  with  the  members  of  the  team  during  the  first  working  session 
on  Tuesday  morning,  22  March.    The  team  also  began  to  develop  an  in- 
depth  interpretation  of  its  charge  through  unstructured  and  far-ranging 
discussion. 

A  structured,  top-down  approach  to  the  problem  was  initiated 
toward  the  end  of  our  first  working  day  and  work  continued  along  this 
course  during  the  second  working  session  on  Wednesday,  23  March.  It 
culminated  in  four  identifiable  conceptual  modules  which  are  funda- 
mental to  the  development  of  an  open-ended,  structured  model  of  a 
computer  security  audit: 

(i)  Definition  of  three  vital  audit  components,  e.g., 
access  control,  accuracy,  availability. 

(ii)  Morphology  of  systems  and  environments.  Physical 
components,  systems  structure,  and  people  -  with 
five  identifiable  systems  characteristics:  Number 
of  users,  types  of  service,  system  organization, 
user  access,  and  application  mix. 

(iii)  Methodology,  or  the  computer  audit  model,  which 
establishes  a  scorecard  value  for  each  and  every 
parametrical ly  identified  control  capable  of 
being  audited. 

(iv)  Model  validation  through  simulation,  verifying 
empirically  through  four  examples  the  power  of 
the  model  as  well  as  its  completeness. 

An  overview  of  our  findings  is  presented  in  this  report.  The 
Chairman  takes  great  pleasure  in  acknowledging  the  dedicated  assistance 
of  all  team  members  toward  achieving  our  final  goal.    Their  incisive 
thinking,  capability  of  abstraction,  and  expressive  writing  produced 
the  raw  material  for  this  paper.    The  Chairman  is  especially  grateful 
to  Mrs.  Sheila  Brand  for  her  continued  monitoring  of  the  development 
of  this  report  in  addition  to  being  a  member  of  our  team.  However, 
.he  alone  takes  full  responsibility  for  any  errors  of  omission  or  com- 
mission which  may  have  occurred  during  this  editorial  process. 


2.  DEFINITIONS 

The  principal  terms  relating  to  computer  systems  security  used 
in  this  report  are  defined  as  follows: 


6-3 


Environment  -  The  physical  facilities,  systems  architecture, 
and  administrative  functions  which  constitute  an  ADP  system  to  be 
audi  ted. 

Security  Audit  -  An  assessment  of  the  system  of  controls  that 
ensure  the  continuity  and  integrity  of  the  environment  as  defined 
by  management.    An  assessment  of  the  reasonableness  of  these  controls 
is  achieved  by  examining  and  evaluating  controls  over  system  access, 
accuracy,  and  availability. 

System  Access  -  The  ability  and  the  means  necessary  to  acquire, 
store  or  retrieve  data;  to  communicate  with  or  make  use  of  any 
resource  of  an  ADP  system. 

System  accuracy  -  The  state  that  exists  when  there  is  complete 
assurance  that  under  all  postulated  conditions  an  ADP  system  implies 

(i)  total  logical  correctness  and  reliability  of  the  system,  and 

(ii)  logical  correctness  and  completeness  of  the  hardware  and  soft- 
ware necessary  to  implement  protection  mechanisms  and  to  assure  data 
integrity. 

System  Availability  -  The  level  or  quality  of  service,  as  de- 
fined by  the  users,  required  to  perform  their  primary  functions. 


3.  METHODOLOGY 


3.1    Audit  Versus  Design 

The  process  of  performing  a  security  audit  is  closely  related  to 
the  security  determination  study  performed  during  the  initial  devel- 
opment stages  of  a  system  which  is  to  be  secured.    This  conclusion 
was  reached  as  we  attempted  to  develop  a  methodology  which  is  based 
on  an  enumeration  of  all  considerations  applying  to  the  audit  of 
computer  security  in  various  system  environments.    We  determined  that 
specific  computer  related,  physical  and  administrative  environmental 
descriptors  required  close  examination.    They  are  all  interrelated 
and  not  readily  separated.    Our  end  result  was  the  enumeration  of 
those  steps  to  be  taken  first  by  the  design  team  and  then  with 
slight  variations  by  the  auditors.    This  result  should  not  prove  too 
surprising  if  one  examines  the  composition  of  an  effective  design 
team.    To  build  cost- justif iabl e,  comprehensive  and  effective  se- 
curity into  a  system  at  least  one  member  of  that  team  should  have 
the  auditor's  viewpoint  and  hopefully  be,  in  fact,  a  qualified 
auditor.    Thus  we  see  a  two-pronged  role  to  be  played  by  the  audit 
profession.    First,  the  auditor  must  be  an  advisor  to  the  design 
team  providing  essential  inputs  to  the  molding  of  the  system; 
second,  during  the  later,  operational  phase  of  the  system  the  auditor 
must  perform  the  traditional  EDP  auditor  functions  and  reassess  the 
effectiveness  of  the  computer  system  security  design. 
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Below,  we  list  the  steps  necessary  to  arrive  at  an  assessment  of 
system  security  effectiveness,  first  for  the  design  team  and  then  for 
the  audit  team. 

3.2    Steps  the  Design  Team  must  take: 

Step  (1)    DEFINE  overal 1  system  requirements,  objectives,  and 
sensitivity. 

Step  (2)  SPECIFY  the  desired  environment,  based  on  results  of 
Step  (1). 

0    Specification  of  physical  parameters  such  as: 

-  Location  of  system 

-  Construction  of  "container"  (building) 

-  Survivability  of  system  under  disastrous 
conditions  such  as  flood,  fire,  bombing,  etc. 

0    Specification  of  system  parameters  such  as: 

-  Degree  of  information  sharing  (will  there  be 
one  or  multiple  users) 

-  Batch  or  interactive  processing 

-  Centralized  or  distributed  data  bases,  processes 

-  Local  or  remote  access 

-  Appl ication  mix 

0    Specification  of  administrative  parameters  such  as: 

-  Threat  analysis 

-  Personnel  procedures 

-  Organizational  structure 

-  Security  requirements  for: 

(a)  Access  Control 

(b)  Accuracy 

(c)  Availabil ity 

-  Insurance 

-  System  development  procedures 

Step  (3)  SPECIFY  control  techniques  that  can  be  used  to  enforce 
the  environment  as  defined  in  Step  (2). 

At  this  point,  it  may  be  helpful  to  point  out  the  differ- 
ences between  security  objectives,  policy  and  procedures.  The 
objectives  of  the  imposed  controls  in  an  operational  environ- 
ment are  regulation  of  access,  accuracy  and  availability.  The 
translation  of  the  objective  of  access  control  into  policy  may 
take  the  form  of  personal  accountability  for  all  sensitive 
transactions.    The  translation  of  this  policy  into  a  procedure 
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may  take  the  form  of  logging  into  the  system  by  way  of  a 
password,  or  manual  logging  into  or  out  of  a  secure  area. 


Step  (4)    PERFORM  a  line-by-line  cost/protection  analysis.  This 
is  by  far  the  most  crucial  step  in  building  a  set  of 
controls  to  protect  the  system  within  its  environment. 
In  this  step  we  analyze  each  control  line  item  speci- 
fied in  Step  (3)  which  could  be  employed  to  protect 
some  aspect(s)  of  the  system.    The  detailed  cost/pro- 
tection matrix  will  have  hundreds  or  thousands  of 
like  items,  dependent  on  the  complexity  of  the  system. 

For  each  control  requirement  four  judgments  are  made: 

(a)  Cost  of  implementation,  development  and 
operation  of  control. 

(b)  Effectiveness  in  regard  to  maintaining 
access  control . 

(c)  Effectiveness  in  regard  to  maintaining 
accuracy. 

(d)  Effectiveness  in  regard  to  maintaining 
system  availability. 

The  effectiveness  judgments  for  (b),  (c),  and  (d)  are 
finally  translated  into  (subjective)  numeric  values  on  a  scale 
from  0  to  10,  (O=non-effecti ve,  1 0=super-effecti ve) .    This  con- 
forms to  the  current  state-of-the-art.    However,  a  very  desirable 
goal  would  be  to  devise  instead  an  objective  scale  of  measures 
of  effectiveness. 


For  purposes  of  convenience,  the  designer  may  use  a  short- 
hand method  of  rating: 


RATING  =  AC/A/AV 


where:    AC  =  numeric  value  assigned  to  effectiveness 
level  of  Access  Control 

A  =  numeric  value  assigned  to  effectiveness 
level  of  Accuracy 

AV  =  numeric  value  assigned  to  effectiveness 
level  of  Availabil  i ty 

These  ratings  become  part  of  the  system  documentation  and 
are  used  in  Step  (5)  and  by  auditors. 
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step  (5)    PERFORM  Composite  Evaluation.    After  performing  the 

line-by-line  analysis  described  in  Step  (4)  a  specific 
subset  of  these  controls  is  selected  as  the  basis  for 
the  comprehensive  set  of  safeguards.    Management  must 
concur  that  this  subset  provides  the  necessary  depth, 
breadth  and  overlap  of  protection  most  cost-effectively 
for  all  aspects  of  the  environment  -  physical,  systems, 
and  administrative.    In  other  words,  this  is  the  stage 
at  which  the  "risk  assessment"  is  made  and  a  "security" 
system  is  designed  to  meet  the  security  objectives  de- 
fined earlier. 

Step  (6)    INCORPORATE  the  approved  security  controls.  REASSESS 
this  new  TOTAL  environment  in  light  of  the  additional 
features  inserted  into  the  three  environmental  (physi- 
cal, system,  and  administrative)  parameters.    If  these 
additions  do  not  degrade  the  overall  system  effective- 
ness (meeting  requirements  and  objectives,  set  down 
in  Step  (1)  ),  the  designers  are  ready  to  begin  im- 
plementation.   However,  if  after  analyzing  the  total 
new  system,  it  is  found  that  the  objectives  are  no 
longer  effectively  attainable,  an  iterative  process 
must  be  initiated  and  the  designers  go  back  to 
Step  (2),  remolding  the  specifications  of  environment, 
etc.,  until  all  requirements  set  out  in  Step  (1)  are 
effectively  satisfied. 

3.3    Steps  the  Operational  Auditor  must  take: 

Once  the  system  has  been  designed  and  implemented,  it  can  go 
into  operation.    The  auditor  is  now  called  upon  to  assess  effective- 
ness of  security  controls  in  an  operational  mode.    As  mentioned 
earlier,  the  steps  of  the  initial  design  team  and  those  of  the  oper- 
ational auditor  are  very  similar.    In  some  steps  only  the  verb  need 
be  changed.    For  example,  in  Step  (1)  the  designer  DEFINES  systems 
requirements  while  the  auditor  REVIEWS  the  stated  requirements  as 
set  down  by  management. 

Step  (1)    REVIEW  objectives,  requirements  and  sensitivity  as 
documented  by  management  for  the  system  under  audit. 

Step  (2)    DETERMINE  the  nature  of  the  environment  prevailing 
during  actual  system  operation,  independent  of  the 
organizational  descriptions.    The  auditor's  percep- 
tions of  the  physical,  systems,  and  administrative 
setup  may  be  quite  different  from  those  that  were 
specified  during  the  design  stage. 


Step  (3)    IDENTIFY  Control  Techniques  used  to  control  the  en- 
vironment as  perceived  by  the  auditor  in  Step  (2). 


Here  we  see  a  clear  divergence  from  the  design  ap- 
proach.   Where  the  designer  may  have  identified  a 
large  number  of  potential  controls  the  auditor  is 
confined  to  examining  only  that  subset  of  controls 
which  are  actually  implemented.    The  auditor  makes  an 
independent  examination  and  may,  or  may  not,  use  sys- 
tems documentation  as  a  starting  point  for  his/her 
identification  of  the  system's  security  components. 

Step  (4)    PERFORM  line-by-line  cost/protection  analysis.    As  in 
Step  (3),  the  auditor  is  not  concerned  with  all  possi- 
ble safeguards,  but  only  with  those  implemented  and 
properly  functioning  within  the  system,  as  determined 
by  his  audit.    While  the  designer  may  have  given 
values  to  the  components  of  the  AC/A/AV  ratings  on  an 
intuitive,  non-objective  basis,  the  auditor  will  aug- 
ment these  judgmental  determinations  through  hardware, 
software,  and  other  sophisticated  (where  available) 
techniques  to  test  the  effectiveness  of  each  com- 
ponent of  the  rating  for  meeting  the  stated  security 
objectives . 

Step  (5)    PERFORM  a  Composite  Evaluation.    The  auditor  now 
assesses  the  total  effectiveness  of  the  security 
system  to  determine  whether  it  meets  the  objectives 
set  by  Management.    A  comparison  can  thus  be  made  of 
the  designer's  rating  and  that  found  by  the  auditor. 
Since  the  measures  used  by  designer  and  auditor  are 
perhaps  different,  this  will  be  only  a  qualitative, 
albeit  incisive,  comparison. 

Step  (6)    PREPARE  report  of  audit  findings  including  reconmen- 
dations  for  upgrading  security  where  weaknesses  are 
found,  e.g.,  where  the  rating  of  the  designer  exceeds 
that  determined  through  audit.    It  is  also  incumbent 
upon  the  auditor  to  recommend  changes  in  overall  se- 
curity control  requirements  if  the  environment  has 
changed  from  that  assumed  during  the  initial  design 
or  since  an  earlier  audit. 


4.    ENVIRONMENT  AND  CONTROL 


The  key  element  of  any  systematic  audit  approach  Is  a  close 
link  between  the  design  and  the  audit  processes  while  maintaining 
a  separation  of  duties  between  designer  and  auditor.    Care  must  be 
taken  to  insure  that  the  same  factors  which  influenced  the  design 
process  are  well  understood  and  given  appropriate  consideration  in 
the  audit  process.    Two  major  factors  must  be  considered:  the  first 
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is  the  environment  in  which  the  system  is  to  operate,  and  the  second 
is  the  control  techniques  to  be  employed  to  enforce  that  environment. 
It  is  essential  that  the  design  process  defines  the  environment  in 
which  the  system  is  to  operate  and  that  the  audit  uses  that  same  en- 
vironmental description  as  a  guide.    If  the  operational  environment 
has  changed  from  that  postulated  at  design  time  in  a  manner  impacting 
security  aspects  of  the  system,  this  impact  must  be  analyzed  and  the 
security  control  requirements  must  be  reassessed  as  a  part  of  the 
audit  process  in  a  similar  fashion  to  the  procedure  initially  used  by 
the  design  team. 

The  approach  being  advocated  here  employs  two  rather  sophisticated 
checklists  and  supporting  material.    The  first  checklist  is  used  to 
establish,  in  considerable  detail,  the  environment  in  which  a  system 
is  to  operate.    In  the  case  of  a  new  system  design,  this  is  the  list 
of  desired  system  characteristics.    In  the  case  of  an  existing  system 
under  evaluation,  this  is  the  list  of  already  existing  system  charac- 
teristics.   We  note  that  the  process  described  in  the  previous  chapter 
will  work  with  either  new  systems  being  designed  or  existing  systems 
being  enhanced  or  merely  being  audited.    In  the  audit  process  the 
statement  of  the  environment  is  given.    The  auditor  is  encouraged  to 
point  out  obvious  inconsistencies  in  the  environment,  if  he  observes 
any,  but  the  environmental  checklist  is  his  reference  point  from 
which  he  evaluates  whether  the  control  techniques  specified  by  the 
designer  are  sufficient  to  enforce  the  given  environment. 

The  second  checklist  is  a  description  of  the  generic  classes  of 
control  techniques  which  the  designer  may  employ  to  enforce  the  en- 
vironment in  which  his  system  must  operate.    As  will  be  seen  later, 
these  range  from  physical  locks  and  fences,  through  internal  hardware 
and  software  access  control  checks,  to  administrative  procedures. 
During  the  design  process,  after  the  system  environment  is  established, 
the  designer  selects  those  measures  from  the  control  techniques  check- 
list which  he  wishes  to  utilize  to  protect  his  system.    Each  of  the 
entries  in  the  control  techniques  checklist  represents  a  segment  of  a 
continuum.    Each  item  contains  a  range  of  measures  with  two  related 
variables:    the  degree  of  protection  afforded  and  the  cost.    At  the 
low  range  little  protection  is  achieved  and  usually  cost  is  minimal; 
at  the  high  range,  a  great  deal  of  protection  is  achieved  and  the  cost 
may  be  proportionately  high.    In  the  example  of  physical  locks  on 
doors  the  range  might  be  from  a  simple  padlock  through  a  sophisticated 
electronically  controlled  and  centrally  monitored  door  locking  system, 
with  proportionate  cost  ranges.    Given  the  sensitivity  of  the  infor- 
mation contained  in  the  system  (from  the  environment  statement)  the 
designer  must  select  those  control  techniques  he  wishes  to  employ  and 
the  appropriate  position  on  the  protection/cost  scale  for  each  chosen 
technique  to  provide  in  the  composite  the  necessary  measure  of  se- 
curi  ty  control . 

From  a  security  viewpoint,  there  are  three  basic  criteria  in  de- 
termining the  environment  and  in  evaluating  the  suitability  of 
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control  techniques  to  enforce  that  environment:  access  control,  accur- 
acy, and  availability.    Each  of  these  factors  must  be  addressed  in  the 
environmental  assessment,  and  each  of  the  control  techniques  being 
applied  must  be  rated  against  all  three  factors.    Some  control  tech- 
niques will  not  apply  to  certain  of  these  measures;  for  example  locks 
do  not  affect  the  accuracy  of  the  information  but  they  have  a  signifi- 
cant effect  on  access  control  and  on  availability  of  the  system.  In 
the  environmental  statement  the  degree  of  protection  needed  in  each  of 
these  areas  must  be  stated  and  in  the  overall  evaluation  of  the  control 
techniques  a  rating  by  the  designer  and  the  auditor  of  each  of  these 
measures  must  be  calculated  and  compared  against  the  environmental  re- 
qui  rements . 

Many  of  the  entries  in  the  control  techniques  checklist  are  com- 
plementary.   If  one  measure  is  taken  another  measure  is  perhaps  not 
required.    Investment  made  in  one  control  technique  will  determine  the 
extent  of  the  investment  needed  in  a  complementary  technique.  The 
relationship  between  entries  in  the  control  techniques  checklist  is 
complex.    To  insure  that  sufficient  measures  have  been  taken  to  com- 
pletely but  not  overly  enforce  the  environment,  the  interactive  rela- 
tionship of  controls  within  various  environments  must  be  explained  in 
a  guidelines  book  which  should  accompany  the  checklist  (see  section  5). 
The  guidelines  book  will  describe  relative  levels  of  effectiveness  and 
cost  of  the  various  control  techniques  and  will  provide  relative  as- 
sessments of  feasible  tradeoffs. 

The  designer  establishes  both  the  environment  in  which  the  system 
is  to  operate  and  the  appropriate  control  techniques.    The  process 
employed  by  the  auditor  in  determining  if  sufficient  control  techniques 
have  been  applied  is  quite  similar.    The  designer  scans  the  control 
techniques  checklist  line-by-line,  selecting  appropriate  items  to  be 
employed.    Then  he  evaluates  the  achieved  overall  security  of  the 
system  with  an  overall  performance  analysis  determined  by  logically 
aggregating  the  selected  effectiveness  measures  assigned  to  the  line- 
by-line  entries.    If  this  overall  analysis  does  not  provide  sufficient 
protection,  or  if  it  exceeds  the  constraining  cost  factors,  then  he 
reevaluates  the  control  techniques  or  perhaps  the  environment  itself, 
making  such  changes  as  necessary  to  achieve  the  security  needed  at  a 
suitable  cost. 

The  auditor,  given  the  environment  checklist,  determines  first 
that  the  actual  operational  environment  is  that  assumed  during  the 
design  stage.    He  then  determines  the  control  techniques  which  he  be- 
lieves appropriate  to  achieve  this  environment.    He  compares  his  con- 
trol techniques  checklist  with  that  of  the  designer  and  weighs  the 
differences  so  as  to  have  a  reference  against  which  to  perform  his 
detailed  analysis.    He  performs  a  line-by-line  evaluation  of  the  entries 
in  the  checklist  and  then  an  overall  analysis  similar  to  that  done  by 
the  designer.    Having  completed  the  overall  analysis  he  may  go  back 
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and  adjust  his  assessment  of  the  individual  control  techniques  based 
on  a  more  complete  understanding  of  the  total  system.    The  result  of 
this  audit  process  is  an  overall  rating  of  how  close  the  design  comes 
to  enforcing  the  security  requirements  of  the  operational  environment. 
If  this  audit  process  produces  a  rating  of  sufficient  protection  then 
the  system  can  be  approved  for  use.    If  it  yields  an  insufficient 
rating  then  the  designer  must  go  back  once  again  to  the  control  tech- 
niques list  or  to  the  environmental  checklist  and  make  appropriate 
changes  to  insure  the  necessary  security  of  the  system. 

The  critical  element  in  this  process  is  the  use  of  the  same 
checklist  information  by  both  the  designer  and  the  auditor.  This 
insures  a  comnon  base  from  which  to  discuss  related  matters.    It  is 
this  common  starting  point  that  is  the  crucial  element  of  our  me- 
thodology.   The  selection  of  elements  from  the  control  technique 
checklist  and  the  degree  of  protection  afforded  each  element  are 
often  subjective  and  the  designer  may  wish  to  take  issue  with  the 
auditor  over  specific  ratings  the  auditor  has  given  for  some  of 
these  measures.    The  crucial  point  is  that  all  elements  of  the  de- 
sign are  understood  by  both  the  designer  and  the  auditor  in  a  common 
context.    This  complete  and  common  listing  of  measures  used  by  both 
the  designer  and  auditor  is  an  element  that  has  been  lacking  in 
previous  audits. 

4.1  Checklists 

Both  the  environmental  and  control  techniques  checklists  are  di- 
vided into  three  sub-categories:  Physical,  system,  and  administrative. 
In  the  environmental  checklist  under  the  physical  heading  are  those 
elements  of  the  physical  environment  which  materially  affect  security 
of  the  system.    Included  is  the  geographic  location  of  the  system, 
taking  into  account  the  susceptibility  to  natural  and  man-made  dis- 
asters such  as  floods  and  crime,  any  special  power  or  air-conditioning 
requirements,  etc. 

In  the  system  environment  list  are  those  measures  which  describe 
the  internal  structuring  of  the  system.    In  particular  we  find  here 
those  elements  which  affect  the  requirement  to  rely  on  internal  hard- 
ware/software measures  to  enforce  the  security  of  the  system.  Under 
administrative  measures  are  included  such  factors  as  the  sensitivity 
and  correctness  of  the  information  contained  in  the  system,  postu- 
lated threats  to  the  system,  etc. 

The  system  environment  comprises  five  physical  and  logical  com- 
ponents or  main  categories: 

1.  Degree  of  Sharing:  Single  vs.  multiple  user(s) 

2.  Type  of  Service:  Batch  vs.  Interactive 

3.  Organization:  Centralized  vs.  Distributed 

4.  User  Access:  Local  vs.  Remote 

5.  Application:  Dedicated  vs.  Multi-purpose 
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The  control  techniques  checklist  is  comprised  of  the  same  three 
categories:  physical,  system  and  administrative.    The  physical  con- 
trols include  the  traditional  "put  the  system  in  a  vault"  measures, 
including  perimeter  control,  hazard  protection  and  backup  mechanisms. 
System  controls  include  hardware/software  access  control  techniques, 
program  integrity  measures,  audit  trail  techniques  and  failure  re- 
sponse procedures.    Administrative  control  techniques  include  what 
are  commonly  referred  to  as  Change  Control  Procedures.    Each  of  the 
control  techniques  must  be  evaluated  against  each  of  the  access  con- 
trol, accuracy,  and  availability  factors  and  an  overall  score  must  be 
arrived  at  for  each  of  those  factors. 

4.2    Guideline  Book 

A  critical  element  in  the  methodology  described  here  is  the 
background  material  which  supports  the  checklist.    This  guideline 
will  be  composed  of  two  sections.    The  first  has  a  line-by-line  des- 
cription of  the  elements  of  the  environmental  and  the  control  tech- 
niques checklists;  in  the  latter  case  the  range  of  protection  cost 
of  each  of  the  entries  is  given.    The  environmental  checklist  must 
be  cross-referenced  against  the  control  techniques  checklist  so  as  to 
insure  that  if  a  particular  element  of  the  environment  is  specified, 
some  range  of  control  techniques  can  be  applied. 

Another  element  of  the  guideline  book  must  deal  with  the  inter- 
relationship between  control  techniques.    From  it  both  the  designer 
and  the  auditor  must  be  able  to  determine  that  if  a  certain  control 
technique  is  employed,  this  may  very  well  negate  the  need  for  another 
control  technique.    An  obvious  example  is  that  if  sufficient  physical 
control  measures  are  taken  and  if  all  personnel  associated  with  the 
system  have  equal  access  to  the  information  on  the  system  then  re- 
liance on  internal  software  access  control  techniques  may  be  sig- 
nificantly relaxed.    This  evaluation  guideline  is  highly  sensitive 
to  the  state  of  technology  and  will  need  to  be  updated  frequently. 
Specifically,  the  relationship  between  cost  and  effectiveness  of  a 
particular  form  of  protection  will  need  to  be  revised  frequently, 
and  new  techniques  will  have  to  be  introduced  as  they  are  developed 
and  become  viable. 

This  overall  methodology  is  a  systematic  approach  to  the  problem 
of  auditing  a  computer  security  installation.    The  approach  is  sys- 
tematic since  the  designer  and  the  auditor  as  well  work  from  a  com- 
plete list  of  both  the  environment  in  which  the  system  is  to  operate 
and  the  control  techniques  which  are  to  be  employed  to  enforce  that 
environment.    By  working  from  common  lists,  the  designer  and  the 
auditor  can  more  readily  communicate  differences  in  their  evaluation 
and  reconcile  their  evaluations. 

A  number  of  such  checklists  are  already  in  existence;  they  can 
be  used  to  form  the  basis  of  the  environment  and  control  techniques 


6-12 


checklists.    The  establishment  of  a  complete  and  accurate  guidebook 
giving  both  the  line-by-line  descriptions  and  the  element  interrela- 
tionships is  a  crucial  element  of  this  overall  methodology  yet  to  be 
accomplished.    For  example,  see:    Data  Processing  Security  Evaluation 
Guidelines;  Peat,  Marwick,  and  Mitchell  &  Co.,  Certified  Public  Ac- 
countants; 345  Park  Avenue,  New  York    NY  10022. 


5.  GUIDELINES 


In  section  3  we  discussed  audit  methodology  and  the  sequence  of 
steps  which  an  auditor  will  follow,  preparatory  to  executing  his  audit 
function  addressed  here.    Therefore,  the  purpose  of  this  section  is 
to  discuss  those  considerations  which  comprise  the  "ideal"  against 
which  the  auditor  compares  and  measures  data  security  in  various  sys- 
tem environments. 

The  "ideals"  are  derived  from  several  sources,  including:  (1)  In- 
formation and  experience  which  the  auditor  brings  to  his  task,  and 
(2)  Information  and  observations  gathered  by  the  auditor  in  his  effort 
to  more  fully  understand  the  system  to  be  audited. 

In  this  section  we  will  not  attempt  to  create  an  actual  book  on 
audit  guidelines.    Several  such  reference  materials  exist  already. 
Furthermore,  the  brief  time  available  for  this  workshop  precludes  any 
such  (exhaustive)  effort.    However,  as  shown  in  the  charts  appearing 
in  the  Appendix,  we  have  attempted  to  identify  significant  categories 
of  control  techniques,  as  well  as  (in  selected  instances)  some  more 
specific  security  measures.    While  the  various  options  within  the 
control  technique  categories  can  be  expanded  upon  by  utilizing  ma- 
terials contained  in  reference  works  (and  from  the  auditor's  own 
knowledge  and  experience)  we  have  chosen  categories  of  control  tech- 
niques which  reflect  major  security  options  (in  a  general  sense)  that 
also  provide  an  opportunity  for  analysis  of  the  differences  among 
selected  system  environment  examples. 

Our  discussions  indicated  clearly  that  there  are,  theoretically 
speaking,  many  possible  system  environments,  resulting  from  a  com- 
bination of  physical,  administrative,  and  systems  design  points  of 
view.    In  order  to  respond  to  the  mandate  given  this  group,  we  chose 
four  sample  systems  which  differed  significantly  from  one  another, 
representing  four  of  the  most  prevalent  kinds  of  systems  existent  in 
today's  computer  processing  environment. 

The  description  of  the  "environment"  for  each  of  the  four  sample 
systems  is  given  in  the  Appendix;  the  method  by  which  the  constituent 
elements  of  an  "environment"  were  ascertained,  was  discussed  in  sec- 
tion 4  on  environment  and  control.    The  kinds  of  control  techniques 
which  we  have  assigned  as  possible  protective  measures  with  respect  to 
the  four  sample  systems  were  briefly  explained  in  that  same  section. 
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However,  our  group  took  the  further  step  of  assigning  subjective  nu- 
merical scale  values  (ranging  from  a  low  of  0  to  a  high  of  10)  to  the 
three  categories  of  control  techniques.    Our  choice  for  these  values 
was  derived  from  the  group's  consensus  of  whether  such  control  tech- 
niques would  be  important  with  respect  to  the  sample  system.  This 
importance  factor  was  considered  for  each  of  the  three  basic  cate- 
gories of  protection  which  our  definition  of  "security  audit"  gave 
their  AAA  (AC/A/AV)  rating:    1.  Access  control,  2.  Accuracy,  and 
3.  Availability. 

It  is  clear  that  there  are  certain  general  audit  considerations 
which  an  auditor  will  utilize  in  determining  the  vulnerability  of  a 
given  system.    These  are  the  experience  items  which  the  auditor  must 
bring  with  him,  to  successfully  complete  the  assigned  task. 

In  the  Appendix,  therefore,  we  considered  only  some  specific 
aspects  of  the  four  sample  systems.    We  highlighted  those  that  affect 
security  considerations  in  a  way  that  distinguished  one  system  from 
another.    Obviously,  in  a  complete  audit  of  security,  one  would  ex- 
pect an  auditor  to  perform  a  much  more  comprehensive  analysis.  But 
we  assumed  that  the  purpose  of  the  mandate  given  to  our  group  was  to 
focus  upon  specific  problem  areas  in  different  system  environments  to 
which  an  auditor  should  pay  particular  attention.    The  more  general 
case,  as  the  proverbial  textbooks  explain,  will  be  left  as  an  exercise 
for  the  reader. 


6.  CONCLUSIONS 


William  C.  Mair,  co-author  of  Computer  Control  and  Audit,  re- 
cently observed  that  "DP  Auditors  are  not  and  cannot  be  policemen." 
He  stated  that  the  primary  responsibility  of  the  DP  Auditor  is  to 
act  as  an  advisor  to  management,  to  emphasize  the  need  for  standards 
which  must  be  properly  documented  and  communicated.    Standards  serve 
as  the  foundation  on  which  everything  else  is  built:    they  provide 
direction,  predictability  and  criteria  for  evaluation.  Through 
these  standards  the  auditors  establish  systems  controls  which  in  turn 
help  reduce  adverse  effects  encountered  in  a  basically  hostile  en- 
vironment.   In  fact,  the  auditor  is  part  of  these  controls. 

Areas  of  vulnerability  must  be  exposed  to  reduce  risks  to  ac- 
ceptable levels.    The  dangers  confronting  EDP  systems  include,  above 
all,  erroneous  management  decisions;  but  also  embezzlement  and  fraud, 
loss  or  destruction  of  assets,  excessive  costs  and  deficient  revenues. 
Their  impact  can  be  severe,  leading  to  competitive  disadvantage, 
statutory  sanctions,  even  to  economic,  political,  and  military  dis- 
asters. 

We  must  not  ever  underestimate  the  power,  ingenuity  and  perse- 
verance of  the  "enemy".    As  we  relate  development  of  controls  to 
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potential  exposures,  we  must  follow  a  rather  simple-minded  approach: 
if  we  can  think  of  it,  someone  else  can  also.    Thus  the  auditor  must 
be  ingenious  about  gathering  basic  and  detailed  information;  about 
evaluating  the  system's  strengths  and  weaknesses;  and  about  testing 
its  design  and  performance.    He  must  review  all  of  its  components 
individually  and  collectively  according  to  a  structured  model  spe- 
cifically designed  for  that  purpose  . 

A  definitive,  open-ended  model  has  been  developed  to  structure 
both  the  initial  internal  design  and  the  follow-up  (external)  com- 
puter security  audits  in  various  system  environments.    The  model  is 
predicated  on  the  notion  that  for  a  system  to  be  viable  within  a 
well-defined  (and  definable)  environment,  we  must  certainly  maintain 
control  over  access  to  the  system,  must  provide  accurate  services 
and  must  assure  the  timely  availability  of  these  services  to  the 
users. 

In  making  the  audit,  we  assume  the  availability  of  standard 
guidelines  for  rating  all  identifiable  system  line  items  with  re- 
gard to  their  contribution  to  access  control,  accuracy,  and  avail- 
ability.   A  global  measure  of  security  audit  can  thus  be  derived 
from  the  line  items'  individual,  local  ratings.    A  number  of  algo- 
rithms have  been  suggested  for  converting  the  aggregate  "local"  into 
"global"  ratings,  but  it  appears  as  if  only  absolute  and  total  com- 
pliance with  the  design  specification  ratings  will  be  acceptable  in 
the  security  environment. 

In  summary,  we  find  that  people  are  the  critical  element  in  all 
computer  security  audits.    To  attain  perfect  security,  therefore, 
we  are  left  with  an  obvious  choice:  Either  we  abolish  computers 
or  we  abolish  people... 
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APPENDIX:    FOUR  EXAMPLES 


To  determine  the  effectiveness  of  the  proposed  methodology,  four 
representative  types  of  systems  covering  various  facets  of  the  system 
environment  were  partially  analyzed.  The  results  of  the  analyses  are 
discussed  here. 


1 .    SYSTEM  SELECTION 

The  four  system  types  selected  reflect  at  least  one  example  of 
each  category  in  the  wide  spectrum  of  possible  system  environments: 

1  -  College  computing  center 

2  -  Airlines  reservation  system 

3  -  Electronic  funds  transfer  system 

4  -  Welfare  check  disbursement  system 

The  objectives/requirements  of  each  system  were  discussed  and 
pertinent  constraints  and  assumptions  were  indicated.    As  the  analy- 
sis proceeded,  further  assumptions  about  the  system  objectives  or 
constraints  were  required  for  clarification.    For  example,  it  was 
assumed  that  the  college  computing  center  was  used  strictly  for 
training  purposes  and  for  nonsensitive  research.    No  sensitive  infor- 
mation (e.g.  grades,  payroll,  etc.)  and  no  critical  applications 
(e.g.  class  scheduling)  would  be  placed  on  the  system.  Similarly, 
it  was  assumed  that  the  airlines  reservations  system  had  extremely 
high  availability  requirements  but  could  tolerate  errors  to  some 
"reasonable"  extent.    The  electronic  funds  transfer  system  was  as- 
sumed to  be  a  network  of  individual  processors  located  in  separate 
financial  institutions,  retail  outlets,  etc.  linked  via  crypto- 
graphically  protected  lines  to  provide  for  the  transfer  of  funds  be- 
tween sites  as  one  of  their  functions.    The  welfare  check  disburse- 
ment system  was  considered  typical  of  large  singl e- function  dedicated 
funds  disbursement  systems  much  like  a  dedicated  system  to  prepare 
corporate  payrolls.    It  was  assumed  that  inputs  arrived  on  magnetic 
tape  and  one  run  per  month  was  made  to  prepare  the  checks. 


2.    DETERMINATION  OF  ENVIRONMENT 

2.1  Physical 

Two  factors  were  selected  as  typical  of  physical  environmental 
concerns  which  must  be  covered  by  the  audit:  location  and  surviv- 
ability requirements  of  the  system. 

2.2  Systems 

The  systems  environment  was  the  main  focus  of  this  workshop. 
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The  five  systems  aspects  to  be  considered  are: 

.  Degree  of  sharing  (single  or  multiple  user) 

.  Type  of  service  (batch  or  interactive) 

.  System  organization  (centralized  or  distributed) 

.  User  access  (local  or  remote) 

.  Applications  mix  (single-dedicated  or  multiple) 

As  indicated  above,  the  four  chosen  systems  together  call  upon 
each  system  environment  aspect  at  least  once. 

2.3  Administrative 

Two  representative  areas  of  administrative  environmental  factors 
were  considered  here:  the  sensitivity  of  the  system  and  the  postulated 
threats  to  the  system. 

After  we  selected  the  factors  for  analysis,  the  workshop  members 
collectively  discussed  them  and  determined  the  corresponding  impli- 
cations for  each  of  the  four  systems.    Obviously,  in  an  actual  audit, 
many  more  environmental  factors  need  be  considered.    Typically,  ap- 
propriate elements  will  be  selected  for  consideration  from  an  ex- 
haustive enumeration  of  security  related  factors. 


3.    IDENTIFICATION  OF  CONTROL  TECHNIQUES 

After  the  sample  environmental  factors  had  been  established  for 
each  system,  a  representative  sample  of  control  techniques  was  de- 
veloped by  group  consensus.    Again,  this  work  would  typically  be  done 
with  the  help  of  an  exhaustive  list.    Several  techniques  for  each 
category  (physical,  systems,  and  administrative)  were  selected  for 
evaluation. 

3.1  Physical 

.    Perimeter  controls  -  this  would  be  a  composite  (in  this  example) 
based  on  both  people  and  "things".    Various  "layers"  of  perimeter 
controls  would  be  considered  (site,  building,  room,  wall  thick- 
ness, doors,  locks,  enclosure,  etc.)  and  various  aspects  (ducting, 
filter,  fire  protections,  air  conditioning,  T.V.  monitors, 
guard  forces ,  etc. ) 

.    Backup  site  -  locations,  security,  availability,  etc. 

.    Disposal  controls  -  control  of  output,  shredding,  etc. 

.    Communications  protection  -  link-by-link  encryption,  shielded 
conduits,  etc. 
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3.2  Systems 

Internal  access  controls  -  hardware/software  controls  for 
identification/authentication,  access  authorization,  enforcement 
methods,  etc. 

.    Program  integrity  measures  -  controls  on  self-checking,  correct- 
ness, reliability,  etc. 

.    Error  detection/correction  -  cyclic  redundancy  checks,  redundancy, 
monitors,  sel f- testing,  etc. 

.    Audit  trails 

Failure  response  -  sotware  and  hardware 

.    Communications  -  end-to-end  encryption  methods 

3.3  Administrative 

.    Perimeter  access  procedures 
.    Maintenance  Procedures  -  software  and  hardware 
Backup  procedures  -  off  line  and  on  line 

Personnel  procedures  -  training,  indoctrination,  bonding,  etc. 

.    Development  procedures  -  standards,  configuration  management, 
certification,  etc. 


4.    CONTROL  ANALYSIS 

Once  the  sample  control  techniques  were  enumerated,  each  system 
was  evaluated  on  a  scale  from  0  (completely  lacking)  to  10  [maximum) 
against  each  control.    Three  criteria  were  used  for  each  evaluation  - 
the  relative  degree  to  which  the  control  in  that  environment  provided 
protection  with  respect  to: 

Access  control  to  system 
Accuracy  of  system 
Availability  of  system 

All  members  of  the  workshop  participated  in  the  discussion  of 
each  item  and  an  overall  consensus  was  used  to  arrive  at  the  results 
shown.    Some  results  reflect  our  impressions  of  actual  systems  where- 
as others  reflect  possible  "design  objectives".    Th.e  following  figures 
show  the  results  of  our  sample  analyses. 
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5.    COMPOSITE  EVALUATION 


The  next  step  would  be  to  derive  an  overall  composite  rating  for 
the  degree  to  which  the  system  provides  protection  with  respect  to 
availability,  accuracy  and  access  control;  and  to  compare  that  with 
the  security  objectives  determined  by  the  system  manager.    This  com- 
parison must  include  analyses  of  tradeoffs  between  the  various  con- 
trols (i.e.  good  physical  controls  may  permit  relaxed  systems  con- 
trols or  vice  versa).    It  must  also  evaluate  the  "weakest  link  in 
the  chain."    A  satisfactory  technique  for  doing  this  must  yet  be 
developed. 

One  suggested  approach  would  be  to  prepare  parametric  "ranges" 
or  "maximum"  values  for  each  control  technique  line  item  as  a  func- 
tion of  a  specific  system  environment  under  evaluation.    These  criti- 
cal values  could  then  be  aggregated  by  subsystems  to  yield  critical 
parameters  for  their  assessment.    For  example,  an  acceptable  critical 
value  for  a  subsystem  may  be  defined  as  the  highest  numerical  param- 
eter selected  from  the  entire  set  of  parameters  which  make  up  the 
line  items  for  this  subsystem.    Conceptually,  we  can  continue  this 
process  of  aggregation  hierarchically  until  all  microscopic  levels 
of  control  adequacy  on  the  (lowest)  line  item  level  have  been  trans- 
lated into  macroscopic  parameters  on  higher  subsystem  levels.    It  is 
perfectly  conceivable,  even  at  this  very  preliminary  stage  of  the 
investigation,  that  a  "standard"  scale  for  system  security  may  even- 
tually evolve  from  the  crude  beginnings  postulated  here. 
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PART  VII:    ADMINISTRATIVE  AND  PHYSICAL  CONTROLS 


Chairperson 


William  Hugh  Murray 
IBM  Corporation 


Participants : 


W.  Gregory  McCormack  II 
Western-Southern  Life 

Eldred  Nelson 
TRW  Systems  Group 

Kenneth  T.  Orr 

Langston,  Kitch  &  Associates 


Susan  K.  Reed,  Recorder 
National  Bureau  of  Standards 

Barry  Wilkins 
IBM  Corporation 


\ 


From  left  to  right:    Kenneth  T.  Orr,  Susan  K.  Reed,  Robert  V.  Jacobson 
(visiting  session  coordinator),  William  Hugh  Murray,  Barry  Wilkins, 
Eldred  Nelson,  W.  Gregory  McCormack  II 


Note:    Titles  and  addresses  of  attendees  can  be  found  in  Appendix  A. 
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EDITORS'  NOTE 


A  brief  biography  of  the  Session  Chairperson  follows: 

Mr.  William  Hugh  Murray  is  Senior  Marketing  Support  Administrator 
in  the  Data  Security  Support  Programs  Department  of  IBM's  Data  Process- 
ing Division.    He  previously  managed  the  development  of  the  security 
sub-system  for  IBM's  Advanced  Administrative  System.    He  is  the  author 
of  the  IBM  publication  "Data  Security  Controls  and  Procedures,"  of  five 
IBM  training  videotapes  on  data  security,  and  a  contributor  to  such 
other  IBM  publications  as  "Considerations  of  Physical  Security  in  a  Com- 
puter Environment."    A  frequent  speaker  on  data  security  topics,  he  has 
appeared  on  national  programs  of  the  AICPA,  EDP  Auditors  Assoc.,  INFO 
76,  and  Data  Comm  77.    He  has  appeared  before  SHARE  and  GUIDE  in  the 
U.S.  and  the  Diebold  Research  Program  in  Europe.    In  1974,  he  chaired 
the  Audit  Working  Group  of  the  NBS/ACM  "Workshop  on  Controlled  Acces- 
sibility in  Shared  Resource  Computer  Systems."    He  holds  a  BS  in  Busi- 
ness Administration  from  Louisiana  State  University. 


The  charge  given  to  this  session  was: 

ADMINISTRATIVE  AND  PHYSICAL  CONTROLS:  What  are  the  audit  approaches 
and  techniques  for  evaluation  of  administrative  and  physical  con- 
trols in  an  ADP  environment,  including  contingency  planning,  etc. 

Administrative  controls  are  defined  to  include  both  procedural  and  per- 
sonnel security  as  follows:    Procedural  security  -  The  management  con- 
straints, operational  procedures,  accountability  procedures,  and  sup- 
plemental controls  established  to  provide  an  acceptable  level  of  protec- 
tion for  sensitive  data.    Personnel  security  -  The  procedures  establish- 
ed to  insure  that  all  personnel  who  have  access  to  any  sensitive  infor- 
mation have  the  required  authorities  as  well  as  all  appropriate  clear- 
ances. 

Physical  controls  include  the  use  of  locks,  guards,  badges,  and  similar 
administrative  measures  to  control  access  to  the  computer,  related 
equipment,  and  information  media.    Further,  it  includes  the  measures  re- 
quired for  protection  of  the  structures  housing  the  computer,  related 
equipment  and  their  contents  from  damage  by  accident,  fire,  and  environ- 
mental hazards. 

This  session  is  to  address  the  audit  approaches  and  techniques  for  eval- 
uation of  administrative  and  physical  controls  with  emphasis  on  those 
areas  that  have  not  been  subjected  to  extensive  coverage  in  the  litera- 
ture.   FIPS  PUB  31  can  be  used  as  a  departure  point  for  this  session. 


This  is  a  report  of  the  consensus  arrived  at  by  the  working  group. 
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REPORT  OF  THE  WORKING  GROUP  ON 
ADMINISTRATIVE   &   PHYSICAL  CONTROLS 
CONSENSUS  REPORT 

WILLIAM  H.   MURRAY,   BARRY  WILKINS 


1.      REVIEW  OF   THE  CHARGE 


The  invitational  workshop  on  audit  and  evaluation  of 
computer  security  was  convened  to  "develop  real  solutions 
to  computer  security  audit  problems".     Since  the  technology 
is  replete  with  "non-problems"  and  "psuedo  problems",  this 
working  group  elected  to  interpret  the  instruction  to  mean 
"real  solutions  to  real  problems" . 

This  working  group  was  asked  to  address  the  audit  ap- 
proaches and  techniques  for  evaluation  of  administrative 
controls  and  the  contribution  of  those  controls  to  securi- 
ty.    We  were  asked  to  place  our  emphasis  on  areas  that  are 
not  already  the  subject  of  extensive  coverage  in  the 
literature,  and  we  were  also  invited  to  comment  on  the 
adequacy  of  the  literature.     In  this  report  we  will  review 
the  context  or  the  environment  in  which  we  have  attempted 
to  address  the  charges,  i.e.,  the  traditional  role  of  the 
auditor  and  its  relationship  to  security.     It  was  the 
consensus  of  the  group  that  a  number  of  problems  do  exist 
in  this  area  and  we  have  attempted  to  articulate  those 
problems.     Some  of  those  problems  are  problems  for  the 
auditor  and  we  have  attempted  to  set  forth  suggestions 
that  the  auditor  may  find  useful  in  responding  to  those 
problems.     Other  problems  relate  to  the  "state  of  the 
practice",  the  literature,  and  the  direction  of  the  tech- 
nology.    These  must  be  addressed  by  the  broader  data 
processing  community.     We  have  attempted  to  identify  these 
issues  and  make  some  broad  recommendations. 


2.      THE  AUDITOR  AND  COMPUTER  SECURITY 


Traditionally,   the  responsibilities  of  the  auditor 
have  included: 

1.  protecting  the  assets  of  the  organization 

2.  ensuring  adherance  to  policy 

3.  and  ensuring  the  adequacy  of  controls  and  proce- 
dures 
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He  has  functioned  by  making  tests  and  examinations 
and  by  reporting  and  recommending.     His  value  to  management 
has  been  that  he  provided  a  view  that  was  independent  of, 
in  addition  to,  and  complimentary  to  the  view  provided  by 
line  management.     Management  would  thus  be  in  a  better 
position  to  act  to  reduce  risk  or  to  accept  it. 

The  auditor's  tests  and  examinations  have  included 
comparing  actual  conditions  to  standards  of  good  practice, 
to  policy  or  other  expectation,  and  to  the  environment. 
Variances  have  been  sorted  between  good  and  bad,  material 
or  immaterial. 

In  allocating  his  resources,  the  auditor  has  been 
guided  by  the  mandate  to  maximize  materiality,  that  is,  he 
wants  to  devote  his  resources  in  such  a  way  that  his  find- 
ings deal  with  the  most  signficiant  risks  to  the  activity. 

Security  has  traditionally  dealt  with  protecting 
mission  resources,  i.e.,  people,  facilities  and  data,  from 
all  natural  and  man-made  hazards.     More  specifically,  data 
processing  security  has  been  concerned  with  protecting  all 
of  the  resources  associated  with  the  DP  mission,  plus  all 
data  within  DP  custody. 

It  should  be  clear  that  since  they  are  both  concerned 
with  protecting  resources  and  assets,  security  and  audit 
complement  each  other.     Where  the  DP  resource  is  signifi- 
cant to  the  organization  or  where  data  in  DP  custody  is 
essential  to  the  effective  control  of  other  signficiant 
resources,  then  it  should  also  be  clear  that  audit  of  DP 
security  will  indeed  be  material. 

However,   it  follows  that  in  order  for  the  auditor  to 
fulfill  his  role,  vis-a-vis  computer  security,  it  is 
essential  that  he  have  a  workable  definition  of  security, 
an  explicit  statement  of  policy  and  accepted  standards  of 
good  practice.     As  in  other  audits,  he  must  have  access  to 
the  function  to  be  audited  and  adequate  resource.     He  must 
know  what  tests  and  examinations  are  appropriate  for  the 
assets  to  be  protected  and  the  hazards  to  which  they  are 
subject.     Finally,  he  must  know  how  to  allocate  his  limited 
resource  in  such  a  way  as  to  maximize  the  usefulness  of 
his  findings,  and  he  must  know  how  to  communicate  those 
findings  in  such  a  way  as  to  maximize  management  under- 
standing and  acceptance.     It  is  the  experience,  finding 
and  conclusion  of  the  members  of  the  working  group  that  the 
auditor  is  encountering  some  problems  in  each  of  these  areas. 
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3 .  PROBLEMS 


It  was  the  consensus  of  the  group  that  sufficient 
problems  exist  in  the  area  of  our  charge  to  justify  our 
efforts,  and  that  in  our  report  we  can  make  suggestions 
and  recommendations  that  will  clearly  contribute  to  their 
solution . 

It  was  suggested  by  one  member  of  the  group  that  in 
audits  of  computer  security  the  auditor  suffers  with  a 
definition  of  security  that  is  binary  and  absolute.  Such 
a  definition  may  result  in  the  conclusion  that  the 
presence  of  a  control  is  always  good  and  its  absence  is 
necessarily  bad.     It  was  the  consensus  of  the  group  that, 
more  often  than  not,  an  organization  will  have  no  explicit 
statement  of  its  security  policy,  nor  any  explicit  assign- 
ment of  security  responsibility.     While  in  this  instance 
the  auditor  may  still  audit  to  standards  of  good  practice, 
he  will  likely  consume  more  resource  and  be  less  effec- 
tive,  since  the  set  of  good  practices  is  larger  than  the 
set  of  specific  practices  that  may  have  been  adopted  by  an 
organization . 

It  is  the  experience  of  the  group  that  in  reconciling 
to  standards  of  good  practice,  the  auditor  is  likely  to 
encounter  a  variety  of  problems  including: 

1.  The  documentation  of  the  standards  of  good 
practice  is  not  adequate  or  useful  for  his 
purpose;   e.g.,   "Computer  Control  Guidelines" 

[1]   documents  general  standards  of  good  practice, 
but  contains  very  little  detail  in  regard  to 
security.     On  the  other  hand,   "FIPS  31"   [2]  is 
very  specific  to  security,  but  is  intended  for 
managers,  not  auditors. 

2.  The  auditor  is  likely  to  find  a  wide  discrepancy 
between  actual  practice  and  good  practice.  When 
confronted  with  a  variance,  the  auditee  will  say, 
"Everyone  does  it  that  way,"    and  he  is  likely  to 
be  right.     Standard  practice  in  data  proces- 
sing is  more  often  a  reflection  of  the  practices 
that  were  appropriate  for  early  data  processing 
systems  than  an  appropriate  adaptation  of 
traditional  standards  of  good  practice.  Often, 
data  processing  management  does  not  even  accept 
that  the  same  rigorous  standards  of  good 
practice  that  are  appropriate  to  the  users  are 
also  appropriate  for  them.     This  variance  between 
"standard"  and  "good"  practice  is  particularly 
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remarkable  in  the  area  of  system  development. 
Even  though  the  variance  is  great  and  the 
problem  significant,   the  auditor  is  frequently 
coerced  into  believing  that  there  is  no  better 
way . 

It  was  the  consensus  of  the  group  that  the  auditor 
has  a  difficult  time  achieving  an  effective  focus  for  his 
audits  of  security  procedures.     This  problem  stems  in  part 
from  the  literature  which  suffers  from  a  terminal  case  of 
"checklistitis" .     Like  the  binary  definition  of  security, 
these  checklists  suggest  that  the  presence  of  a  control  is 
always  good  and  its  absence  necessarily  bad.     They  fail 
to  give  proper  weight  to  the  value  of  the  resources  to  be 
protected,  or  the  consequences  of  their  loss;   the  hazards 
to  which  those  resources  are  exposed  or  their  expected 
rates  of  occurrence;  the  use  to  which  the  system  is  put  or 
the  applications  which  reside  upon  it. 

Finally,  the  working  group  concluded  that  the  auditors' 
report  often  fails  to  receive  the  management  acceptance 
and  weight  that  are  appropriate  to  its  findings.  In 
addition  to  some  of  the  items  noted  above,  a  number  of 
specific  reasons  for  this  were  identified  including: 

1)  The  reports  do  not  discuss  the  standards  that  were 
applied.     The  standards . for  financial  audits  are 
"generally  accepted"  and  do  not  need  to  be  explic- 
itly set  forth.     However,  in  audits  of  security 
there  are  no  "generally  accepted"  standards. 
Therefore,  the  standards  that  are  applied  and  the 
authority  for  them  should  be  explicitly  referenced. 

2)  The  reports  fail  to  give  proper  weight  and 
coverage  to  the  level  of  compliance  that  was 
found.     Audit  reports  often  discuss  the  level  of 
compliance  found  in  a  paragraph  and  then  spend 
pages  on  the  variances. 

The  working  group  articulated  a  number  of  suggestions 
which  it  hopes  that  the  auditor  will  find  useful  in 
improving  his  efficiency  and  effectiveness. 


4.      SUGGESTIONS  FOR  THE  AUDITOR 


In  response  to  the  problems  noted,  the  group  made 
suggestions  on  audit  focus  and  materialitv,   standards  of 
practice  and  their  documentation,  reporting,  and  audit  scope 
and  techniques.     The  first  three  areas  are  treated  in  this 
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chapter.     Audit  scope  and  techniques  are  covered  in 
chapters  five  through  10. 

4.1     Audit  Focus  and  Materiality 

In  order  to  maximize  his  effectiveness,  and  recogniz- 
ing that  absolute  security  equals  0  productivity,  the 
group  recommended  that  the  auditor  use  the  concept  of  an 
"acceptable  level  of  risk"   in  whatever  definition  of 
security  he  elects.     Within  this  concept  it  is  permissable 
to  choose  among  protective  measures  rather  than  to  employ 
them  all.     Management  need  not  be  faulted  for  the  absence 
of  a  specific  measure  if  its  absence  does  not  result  in  an 
unacceptable  level  of  risk. 

It  was  the  consensus  of  the  working  group  that  the 
single  most  important  determinant  of  the  sensitivity  of  a 
system  is  the  use  or  application  to  which  it  is  being  put. 
For  that  reason  we  recommend  that  a  helpful  perspective 
from  which  to  view  the  security  of  a  system  is  application 
by  application.     The  most  effective  way  in  which  to 
maximize  materiality  is  to  concentrate  on  the  more  sensi- 
tive applications.     Figure  1  lists  some  of  these  types. 


*  Develops  or  controls  other  applications  (e.g., 
program  development  systems,   security  sub-systems) 

*  Writes  checks   (e.g.,  payroll,  accounts  payable, 
dividends) 

*  Creates  credits    (e.g.,  accounts  receivable) 

*  Controls  convertible  resource   (e.g.,  inventory 
control ) 

*  Controls  or  contains  personal,  proprietary  or 
otherwise  sensitive  data 

*  Controls  or  contains  data  essential  to  rendering 
a  service  or  continuing  operation 

*  Other 


Figure  1.     Indicators  of  application  sensitivity 
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In  security  audits,  as  in  financial  audits,  the 
"Sutton  test"   is  also  useful  for  identifying  material  appli- 
cations for  audit.     When  asked  why  he  robbed  banks,  Willie 
Sutton  replied,   "Because  that's  where  the  money  is."  There- 
fore, the  Sutton  test  suggests  that  security  auditors 
should  concentrate  on  applications  whose  scope  includes 
very  high  value  data  or  are  associated  with  high  value 
resources . 

4.2     Standards  of  Practice  and  Their  Documentation 

Five  publications  were  cited  by  members  of  the  group 
as  being  of  particular  value  to  the  security  auditor.  These 
are:     Computer  Control  Guidelines    [1] ,  Computer  Audit 
Guidelines    [3 ] ,   Guidelines  for  ADP  Physical  Security  and 
Risk  Management   [2 ] ,  Data  Security  Controls  and  Procedures 
[4] ,   and  Control  Obj ectives    [5]  . 

Computer  Control  Guidelines  and  Computer  Audit  Guide- 
lines were  considered  to  be  the  most  definitive  and 
authoritative  statement  of  the  standards  of  good  practice 
for  data  processing  and  the  effective  audit  of  same.  They 
are  written  by  auditors  for  auditors.     They  are  well- 
structured  and  easy  to  use.     While  their  scope  is  broader 
than  security,  they  contain  practices  and  tests  which  are 
appropriate  to  security. 

Guidelines  for  Physical  Security  and  Risk  Management 
in  ADP  was  cited  as  the  best  source  for  standards  of  good 
practice  in  physical  security.     It  also  provides  data  on 
the  rates  of  occurrence  of  natural  events  that  is  useful  in 
determining  whether  or  not  a  particular  measure  is  indicated. 
While  complete  and  well-written,  this  manual  is  addressed 
to  managers.     A  thorough  study  of  this  manual  will  be 
required  by  auditors  who  wish  to  use  it. 

Data  Security  Controls  and  Procedures  was  recommended 
as  a  good  source  for  standards  of  good  practice  for  limit- 
ing risk  in  data  processing.     It  also  treats  contingency 
planning  and  systems  design  for  security.     Although  it  is 
addressed  to  management,  it  is  readily  useable  by  auditors. 

Finally,  Control  Obj  ectives  sets  forth  standards  of 
good  practice  for  data  processing  management.     It  specif- 
ically treats  the  standards  for  physical  security.     It  has 
been  found  useful  for  audits  of  DP  practice  in  general  and 
operations  management,   including  security,   in  particular. 
This  publication  was  prepared  by  EDP  auditors  for  them- 
selves, but  the  auditor  who  is  auditing  security  specif- 
ically may  have  to  do  some  excerpting. 
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4.3     The  Security  Audit  Report 

The  working  group  concluded  that  the  style  of  the 
report  of  an  audit  for  computer  security  will  have  a 
significant  impact  upon  its  effectiveness.     The  group 
suggested  that  the  following  format  might  be  useful. 

Executive  Summary 
Purpose 
Scope 

Environment 
Conclusions 

Standards  applied 
Tests  performed 
Compliance  level 
Variances  noted 
Recommendations 
Residual  risk 

The  Executive  Summary  should  be  addressed  to  higher 
management.     In  addition  to  describing  the  boundaries  of 
the  audit,   it  should  describe  the  key  findings  in  such  a 
way  that  the  reader  knows  what  action,   if  any,   is  indicated. 
In  some  instances,  a  thorough  reading  of  the  entire  report 
will  be  indicated  along  with  vigorous  corrective  action. 
In  other  cases,  it  may  be  adequate  simply  to  pass  the 
report  to  the  auditee  for  his  review  and  follow-up.  The 
executive  should  not  have  to  look  beyond  the  summary  in 
order  to  determine  his  action. 

The  balance  of  the  report  should  be  addressed  to  the 
auditee  and  his  management.     Most  of  the  corrective  action 
that  will  be  indicated  by  the  audit  will  be  taken  by  the 
auditee  himself.     Therefore,  it  is  to  him  that  the  report 
should  be  addressed.     Proper  recognition  of  the  fact  that 
the  auditee  is  a  legitimate,  and  perhaps  primary,  audience 
for  the  report  should  contribute  to  a  style  and  content 
that  is  both  helpful  and  acceptable  to  him. 

Since  there  are  no  "generally  accepted"   standards  of 
good  practice  in  EDP  security,   the  report  should  discuss 
the  standards  that  were  applied  and  employed.     This  action 
should  reference  all  organization  policy,  standards,  and 
guidelines  that  were  used  as  well  as  any  external  standards 
that  were  applied.     External  standards  should  be  docu- 
mented or  referenced.     The  authority  for  all  external 
standards  should  also  be  noted. 

In  order  to  properly  evaluate  the  audit  findings, 
management  must  know  something  about  the  time  and  effort 
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that  was  applied  to  it.     The  report  must  describe  the 
manner  in  which  the  audit  was  conducted,   the  value  of  the 
tests  performed,  and  the  resource  consumed.     An  audit  that 
involved  four  people  for  four  weeks  deserves  more  credence 
than  one  that  took  one    (1)   person  one    (1)   week.     It  is  not 
adequate  in  a  security  audit  to  use  the  disclaimer  "such 
tests  as  we  felt  appropriate" . 

The  level  and  nature  of  compliance  found  must  be 
described  in  detail.     This  is  essential  if  management  is 
to  be  able  to  properly  evaluate  the  findings  and  recom- 
mendations.    Variances  are  more  meaningful  when  viewed  in 
the  light  of  the  general  level  of  compliance  found  than 
when  viewed  alone.     Failure  to  give  due  weight  in  the 
report  to  compliance  will  not  only  detract  from  the 
ingegrity  of  the  report,  but  runs  the  risk  of  detracting 
from  its  credibility  and  creating  unnecessary  resistance 
on  the  part  of  the  auditee. 

If  variances  and  recommendations  are  placed  in  the 
context  of  this  kind  of  report,  the  working  group  believes 
that  they  will  receive  the  best  possible  acceptance. 

However,  the  report  should  also  include  assessments 
of  the  residual  risk  both  with  and  without  the  acceptance 
by.  management  of  the  recommendations.     If  the  auditor  has 
difficulty  in  articulating  the  residual  risk,  then  it  would 
be  well  to  think  the  recommendations  through  again. 


5.     TYPES  OF  AUDITS 


5.1  Introduction 

Described  in  the  following  chapters  are  five  different 
audit  approaches  for  reviewing  data  processing  security. 
The  five  approaches  are  not  mutually  exclusive.  However, 
there  are  five  separate  identifiable  modules,  each  of 
which  can  be  done  as  a  separate  audit  or  combined,  depending 
on  the  environment  to  be  audited.     The  five  audit  approaches 
to  be  described  are: 

System  Development  and  Maintenance  Practices  audit 
Application  Review 
Installation  Security  Review 

Security  Function    (Data  Base/Communication  Environ- 
ment) Review 
Compromise  Attempt 
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These  audit  approaches  are  not  treated  in  priority 
sequence.     The  relative  importance  of  each  audit  module 
will  be  determined  by  the  DP  environment  to  be  audited. 
Since  most  audit  staffs  are  limited  in  resources,  it  is 
important  that  adequate  time  is  spent  in  the  pre-audit 
phase  profiling  the  DP  organization  or  installation  to  be 
reviewed.     Only  with  a  basic  understanding  of  the  environ- 
ment to  be  reviewed,  can  it  be  determined  which  modules 
are  applicable,  what  the  scope  of  the  audit  should  be,  and 
where  major  emphasis  should  be  placed. 

The  areas  of  audit  concern,  the  audit  purpose,  the 
audit  approach    (where  applicable) ,   and  proposed  scope  with 
recommended  tests  will  be  described  for  each  of  the  five 
aforementioned  audit  approaches . 

5.2  Checklists/References 

It  is  not  the  intent  of  this  paper  to  provide  a  check- 
list for  each  of  the  subject  audit  approaches.     It  was 
determined  that  there  are  numerous  references  available  on 
the  various  subject  areas  including  checklists.     It  was 
the  consensus  of  our  group,  however,  that  the  best  single 
reference  is  the  Computer  Control  Guidelines  and  the 
Computer  Audit  Guidelines  published  by  the  Canadian  Insti- 
tute of  Charter  Accountants . 

It  should  also  be  recognized  that  any  generalized 
reference  or  checklist  on  the  subject  matter  must  be 
tailored  to  the  environment  under  review.     There  is  no 
global  answer  or  guide  common  to  everyone  and  equally 
applicable . 

The  purpose  of  this  paper  is  to  provide  a  uniform 
approach  that  can  be  supplemented  by  checklists  and  other 
references . 

5 . 3  Approach 

For  all  five  of  these  security  audits  it  is  suggested 
that  the  approach  be  the  best  configuration  of  all  tradi- 
tional audit  techniques  to  include  emphasis  on  the  follow- 
ing techniques  : 

Selective  Protection  -  identify  the  key  effort 
resources  and  concentrate  the  review  efforts  on  how 
those  resources  are  protected. 

Test  -  wherever  possible  verify  procedures  and 
discussions  through  actual  tests    (e.g.,  control  report 
reconciliations) . 
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Interview  -  conduct  interviews  with  all  involved 
employees  and  management  in  computer  operations, 
programming,  users,  security,   legal,  personnel,  etc. 
This  is  an  area  to  be  stressed;  good  interviewing 
techniques  supported  by  adequate  follow-up  testing 
can  greatly  facilitate  the  audit  by  producing  more 
findings  in  a  shorter  period  of  time. 

Technical  Cooperatives    (co-ops)   -  the  use  of  team 
members  on  these  audits  from  other  organizations  or 
locations,  selected  for  their  technical  expertise,  is 
a  very  effective  and  well-proven  technique.     One  word 
of  caution:     the  auditor  should  always  be  in  charge. 

These  are  some  of  the  approaches  and  techniques  that 
the  group  felt  would  be  very  effective  in  conducting  audits 
of  DP  security. 


6.      SYSTEMS  DEVELOPMENT  AND  MAINTENANCE  PRACTICES 


6 . 1  Concern 

In  the  audit  community  today,  there  is  an  ongoing 
debate:     should  the  auditor  be  involved  in  System  Design 
and  Development.     Both  sides  agree:     1)   that  there  is  a 
valid  concern  from  both  a  security  and  control  viewpoint 
that  the  proper  development  of  new  systems  and  applications 
is  important,  2)   that  post-implementation  enhancements 
are  difficult  at  best  to  install,  and  3)   that  the  auditor 
cannot  ignore  his  responsibility  in  this  important  area. 

It  is  necessary  in  many  instances  to  build  very 
tight  security  routines  into  a  system  or  application. 
Therefore,  all  aspects  of  DP  security  should  be  considered 
during  design.     If  proper  security  cannot  be  provided, 
then  it  is  conceivable  a  project  should  be  halted  until 
better  technology  or  controls  are  available.     This  is  an 
extremely  important  audit.     If  security  is  not  being 
built  in  during  design,  it  will  probably  always  be  non- 
existent . 

This  audit  approach  is  presented  as  an  alternative  to 
the  two  extremes  of  the  "System  Design  Debate"  and  as  a 
minimum  level  of  involvement  on  the  part  of  internal 
Auditors.     It  is  an  approach  where  the  auditor  can  review 
the  system  development  process  rather  than  actively 
participate  in  the  content  of  system  design.     It  is 
particularly  applicable  to  those  audit  staffs  that  have 
either  consciously  decided  not  to  become  involved  in  the 

7-12 


content  of  system  design  or  because  of  resource  constraints 
cannot  cover  all  new  development  projects    (large  organ- 
izations) . 

It  was  the  consensus  of  our  group  that  reviewing  the 
management  process  for  system  design  is  an  effective  way  to 
ensure  controls  are  built  into  systems  on  an  ongoing  basis 
and  not  only  when  the  auditor  is  involved. 

6 . 2  Purpose 

The  purpose  of  this  audit  is  to  determine  if  local 
management  is  in  compliance  with  established  procedures  or, 
given  the  lack  of  defined  procedures,  if  local  management 
has  established  and  implemented  adequate  standards  and 
procedures  to  ensure  that  only  secure  systems  and  appli- 
cations are  developed.     The  purpose  of  this  review  is  to 
determine  that  all  aspects  of  security  are  discussed  and 
that  controls  are  implemented  where  necessary  during  the 
development  cycle.     The  auditor  must  determine  that  the 
subject  of  security  is  actually  an  integral  part  of  all 
decisions  made  during  the  development  cycle. 

6  .  3  Appr'oach 

The  audit  approach  will  be  to  interview  local 
personnel  and  management  and  to  actually  sample  current 
and  recently  completed  development  projects  and  associated 
documentation,  to  test  compliance  with  procedures  or,  in 
the  absence  of  such  procedures,  to  determine  if  exposures 
exist  based  on  judgment  and  generally  accepted  business 
practices  for  system  design. 

6 . 4  Scope 

6.4.1    Design  Standards 

The  obvious  place  to  start  an  audit  of  this  nature 
is  by  a  review  of  corporate  and  divisional  design  standards 
and  a  comparison  of  the  local  organization's  procedures  to 
established  company  standards.     An  important  point  to 
remember  is  that  the  auditor  should  recommend  improvements 
to  company  standards  as  well  as  local  policy  when  defi- 
ciencies are  noted. 

During  this  phase  of  the  audit,  the  auditor  will 
familiarize  himself  with  the  company  policy  and  the 
adequacy  of  the  local  operating  procedures.     More  often 
than  not,  a  review  of  local  operating  procedures  will  be 
reflective  of  the  actual  practices.     If  management  has  not 
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taken  the  time  to  adequately  define  development  procedures 
and  formally  assign  responsibility  for  security  controls, 
it  will  be  a  rare  exception  to  find  a  well  controlled  and 
secure  environment  or  product. 

The  Design  Standards  should  discuss  physical,  admin- 
istrative and  technical  controls  in  all  of  the  following 
areas  which  will  be  the  subject  matter  of  this  audit: 

Organizational  Controls 
Access  Control 
Phase  Reviews 
Testing/System  Assurance 
Promotion  Process 
Documentation 

Auditor/Independent  Party  Involvement 
Configuration  Management 
Emergency  Procedures 

The  auditor  should  determine  the  adequacy  of  the 
procedures  in  all  of  the  areas.     The  remainder  of  the 
audit  will  then  be  devoted  to  testing  compliance  to 
established  or  recommended  procedures  as  they  are  imple- 
mented in  the  development  cycle. 

6.4.2  Organization  Control 

The  foundation  of  all  controls  is  the  organization. 
The  auditor  must  evaluate  the  organization  to  determine 
if  it  is  conducive  to  good  security  controls  and  develop- 
ment practices.     Hiring  practices,  separation  of  duties, 
manpower  resources,  skill  mix  and  education,  are  all 
subjects  that  should  be  reviewed  during  this  audit.  In 
this  portion  of  the  audit,  the  auditor  must  determine 
that  the  responsibilities  and  duties  of  the  using  function, 
programming  and  computer  operations  are  clearly  defined 
and  separated;  that  manpower  has  been  properly  allocated 
to  key  control  functions;  that  these  functions  have  the 
required  technical  expertise;  and,  that  the  employees  are 
being  given  adequate  ongoing  education. 

It  is  reasonable  for  the  auditor  to  assess  whether  the 
subject  of  organization  control  is  being  adequately  addres- 
sed during  the  development  cycle. 

6.4.3  Access  Control 

Ensuring  that  access  to  all  proprietary  DP  resources 
is  limited  to  only  those  employees  with  an  absolute  need 
is  key  in  this  audit.     A  lack  of  controls  in  this  area 
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will  expose  proprietary  data  to  unauthorized  access; 
enable  computer  frauds;  possibly  result  in  poor  data 
integrity;  and  poor  documentation. 

Administrative  and  physical  controls  to  limit  access 
to  the  following  DP  resources  should  be  reviewed: 

Facility 

Computer  installation 

Hardware 

Programs 

JCL 

Data 

Output  reports 
All  DP  media 

The  auditor  should  ensure  that  access  control  is 
being  considered  during  system  design  so  that  additional 
access  or  other  controls  can  be  implemented  during  develop- 
ment if  necessary. 

The  auditor  must  test  access  control  procedures  by 
reconciling  actual  employee  accesses  to  DP  resources  to 
management's  list  of  authorized  personnel.     The  auditor 
must  also  determine  if  management  has  limited  the 
authorized  list  to  only  those  with  an  absolute  need. 

6.4.4     Phase  Review/Project  Control 

A  formal,  detailed,   and  documented  phase  review 
procedure  is  necessary  if  management  is  to  exercise 
effective  control  over  system  design.     The  phase  review  is 
a  tool  to  provide  executive  management  with  information 
about  status  of  projects.     Through  the  phase  review  cycle, 
meaningful  checkpoints  are  established,  whereby  critical 
issues  relating  to  development  are  addressed. 

Security  control  is  one  of  these  critical  issues 
which  is  often  overlooked  during  the  phase  review  for  a 
variety  of  reasons. 

From  a  security  viewpoint,  the  auditor  must  review 
the  phase  review  process  and  determine  if  security  is 
considered  as  an  integral  part  of  all  development  projects. 
There  are  many  questions  that  need  to  be  answered.  For 
example,  is  the  security  department  involved?     Is  the  DP 
security  coordinator  involved?     Is  the  user  involved  with 
security?     Is  the  security  system  tested,  etc.? 

The  main  point  that  the  auditor  must  address  is  that 
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in  the  early  stages  of  all  development  cycles  a  security 
philosophy  and  documented  plan  is  developed,  agreed  to, 
and  performance  to  the  plan  is  monitored  throughout  the 
development  cycle.     There  should  be  adequate  documentation 
to  substantiate  that  security  was  not  treated  lightly. 
Management  involvement  and  approach  should  be  evidenced  in 
writing . 

6.4.5  Testing/System  Assurance 

The  auditor  must  ensure  that  all  security  controls 
designed  into  the  system  are  extensively  tested.  A 
comprehensive  test  plan  and  documented  results  should  be 
available  for  review.     Security  should  be  an  identifiable 
category  in  the  test  plan. 

Also,  during  the  test  cycle,  security  exposures  may 
be  created  if  proper  administrative  and  physical  controls 
are  not  put  in  place  to  control  access  to  live  data.  The 
auditor  must  ensure  that  live  data  is  not  used  except 
under  the  most  extreme  circumstances,  and  that  if  it  is 
used,  controls  to  prevent  misuse  are  in  place. 

6.4.6  Promotion  Process 

The  promotion  process  is  the  process  of  transferring 
a  program  from  a  test  status  to  a  production  status.  In 
a  well  controlled  environment,  computer  operations  will 
maintain  ownership  of  all  production  programs,  JCL  and 
associated  documentation,  and  the  programming  function 
will  maintain  control  of  the  programs  while  they  are  in 
a  test  status.     Promoting  a  program,  therefore,  generally 
means  transferring  control  from  the  programming  function 
to  the  operations  function. 

During  this  process,  many  effective  administrative 
and  procedural  controls  can  be  implemented  to  ensure 
security  of  the  programs  themselves,  and  that  security  is 
built  into  the  programs.     The  following  represents  a 
partial  list  of  controls  the  auditor  should  look  for: 

-  Using  function  request/written  authorization 

-  Programming  management  approval/authorization  and 
delegation  to  programmer 

-  Operations  release  of  programs  and  documentation 
based  on  authority 

-  Independent  party  review  of  code  to  detect  errors 
and  deter  programmer  fraud 

-  Separation  of  test  and  development  work  from 
production 
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-  After  promotion,  documentation,  programs,  JCL , 
data,  etc.,  controlled  by  operations 

The  promotion  process  is  an  important  part  of  the 
maintenance  and  development  cycle.     Procedures  and  controls 
during  this  process  must  be  reviewed. 

6.4.7  Documentation 

Auditors  frequently  encounter  poor  documentation 
and  are  advised  that  documentation  is  written  for  pro- 
grammers and  not  auditors.     Poor  documentation  results 
in  applications  and  systems  that  are  not  functional , 
effective,  or  secure,  and  coincidentally ,  are  not  easily 
enhanced,  are  not  understood  and  are  not  auditable. 

While  it  is  recognized  that  poor  documentation  is 
a  universal  problem,  the  auditor  should  not  ignore  it. 
The  product  of  any  system  or  application  development 
effort  must  be  an  adequately  documented  solution  to  a 
problem  or  need.     The  program  or  code  itself  is  only 
one  part  of  the  solution,  but  is  often  given  the  most 
attention  because  its  intended  audience,  the  machine, 
is  the  most  unadaptable  and  unforgiving.     The  intended 
audience  for  the  documented  solution  to  a  problem  includes 
management,  users,  operations  maintainers,  the  machine 
and  auditors. 

Auditors  are  an  appropriate  audience  by  definition. 
Therefore,  auditors  should  be  able  to  understand  the  doc- 
umentation and  should  critique  it  if  they  are  not  able 
to  understand  it.     The  auditor  should  ensure  documentation 
standards  are  adequate  and  are  being  adhered  to  and  should 
no  longer  accept  the  traditional  excuses. 

The  auditor  must  continually  review  and  criticize  the 
lack  of  adequate  documentation. 

6.4.8  Auditor/Independent  Party  Involvement 

Sensitive  programs/systems  should  be  subject  to  an 
independent  review  and  verification.     If  the  auditor  does 
not  directly  participate  in  system  design,  it  is  impor- 
tant that  some  function  be  designated  as  the  independent 
party.     The  auditor  must  review  the  adequacy  of  independent 
party  involvement  during  system  design. 

6.4.9  Configuration  Management 

The  auditor  should  expect  to  find  a  management  system 
or  mechanism  for  controlling  which  versions  of  each 
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component  are  included  in  any  specific  integration  or 
copy  of  a  product  system.     This  management  system  should 
include  an  audit  trail  that  is  adequate  to  determine  for 
any  given  integration  or  copy,  which  version  of  a 
component  was  included.     Tests  should  be  made  for  the 
presence  of  the  system,  its  adequacy  for  the  application, 
that  it  is  being  used  as  intended,  and  that  the  audit 
trail  is  present  and  adequate.     Wiere  indicated,  the 
content  of  the  audit  trail  should  be  reconciled  to  the 
content  of  an  integration  of  a  product  system. 

6.4.10     Emergency  Procedures 

Management  must  have  the  flexibility  to  substitute 
emergency  procedures  for  normal  procedures  when  required 
to  respond  to  unusual  situations.     Emergency  procedure 
will  compensate  for  the  risk  associated  with  extra  flexi- 
bility by  involving  additional  management.     Reviewing  the 
procedures   and  actual  practices  in  the  event  of  an  emer- 
gency program  fix,  to  prevent  the  bypassing  of  established 
controls,  is  an  important  part  of  the  System  Development 
Audit. 

The  auditor  should  expect  to  find  procedures  that 
ensure  that  all  emergency  fixes  are  subjected  to  the 
same  controls  after,  that  the  normal  updates  are  subjected 
to  prior. 

7.      APPLICATION  REVIEW 

7 . 1  Concern 

There  are  important  administrative,  procedural  and 
system  controls  that  should  be  in  place  to  provide  for 
continuous  security  in  all  applications  that  have  been 
implemented.     Either  the  absence  of  or  deficiencies  in  the 
administration  of  these  controls  may  lead  to  exposures. 

7 . 2  Purpose 

An  application  review  is  a  post-installation  analysis 
of  the  data  processing  security  controls  and  procedures 
that  are  unique  to  a  specific  application.     This  is  in 
contrast  to  other  data  processing  security  controls  and 
procedures  that  are  common  across  all  applications  in  a 
computer  environment. 

The  purpose  of  this  review  is  to  ensure  that  the  appli 
cation  was  designed  with  adequate  internal  security  control 
and  that  these  controls  are  being  administered  in  a  consis- 
tent manner. 
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7 . 3  Approach 


Application  reviews  should  be  conducted  by  internal 
auditors  as  an  integral  part  of  all  functional  audits  of 
financial  and  operational  areas.     If  a  functional  area 
depends  on  data  processing,   an  audit  of  that  function  must 
include  a  review  of  the  data  processing  related  controls. 

An  audit  of  the  functional  area  is  not  complete  with- 
out a  review  of  the  DP  application.     Both  parts  of  the 
overall  audit  should  be  done  s5.multaneously . 

7 . 4  Scope 

The  scope  of  an  application  review  will  include 
the  following  eight  areas  as  they  relate  to  a  specific 
application . 

Input/output  controls 

System  internal  control  effectiveness 

Separation  of  duties 

Sensitive  program  identification 

User  satisfaction/involvement 

Report  utilization 

System  documentation 

Vital  records 

Not  all  of  these  areas  are  applicable  to  every  appli- 
cation.    Each  area  is  described  briefly  on  the  following 
pages . 

7.4.1  Input/Output  Controls 

The  system  or  application  should  provide  adequate 
controls  to  ensure  that  only  what  was  authorized  was  pro- 
cessed and  in  its  entirety;  nothing  more  and  nothing  less. 
The  auditor  must  assess  the  adequacy  of  the  control  tech- 
niques and  determine  that  they  are  being  used  as  appropri- 
ate . 

7.4.2  System  Internal  Control  Effectiveness 

The  auditor  must  evaluate  and  test  the  adequacy  of 
internal  edit  and  audit  routines  to  ensure  the  detection 
or  prevention  of  questionable  or  invalid  situations. 

The  auditor  must  determine  if  adequate  internal 
controls  exist  by  reviewing  system  documentation,  inputting 
test  transactions,  questioning  users  and  reviewing 
exception  and  control  reports.     The  key  here  is  to  test 
whenever  possible. 
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7.4.3     Separation  of  Duties 


It  is  clear  that  the  security  of  any  application  is 
dependent  on  the  proper  separation  of  those  duties  normally 
performed  by  the  user,  programming  and  operations  functions. 
For  example,  in  an  accounts  payable  application,  the  user 
should  not  program  or  be  able  to  execute  the  application. 
The  programmer  should  not  be  allowed  to  input  live  data 
or  access  master  files.     The  operator  should  not  reconcile 
control  totals.     Refer  to  section  8.4.2.2  for  a  further 
discussion  on  separation  of  duties. 

7.4.4  Sensitive  Program  Controls 

There  may  be  a  need  for  additional  controls  for 
programs  where  there  is  an  exposure  to  unauthorized 
manipulation  of  program  code  for  the  purpose  of  mis- 
appropriating company  assets.     An  example  of  an  additional 
control  would  be  an  independent  review  of  every  changed 
line  of  coding  made  to  the  accounts  payable  checkwriter 
program.     Such  a  review  would  not  be  necessary  for  other 
programs  even  within  the  accounts  payable  application. 
The  auditor  should  determine  the  "sensitive  programs" 
in  an  application  and  ensure  they  are  provided  with 
"selective  protection". 

7.4.5  User  Satisfaction/Involvement 

The  users  should  be  questioned  during  this  audit 
to  determine  if  they  are  aware  of  known  security  deficien- 
cies that  have  not  been  adequately  resolved.     The  auditor 
must  determine  if  the  user  understands  the  system  and  is 
truly  involved  in  changes  to  it. 

7.4.6  Report  Utilization 

The  auditor  should  determine,  independently  from 
programming  documentation,  the  control  reports  available 
from  the  system  and  determine  if  they  are  used. 

7.4.7  System  Documentation 

The  auditor  must  review  the  adequacy  of  documenta- 
tion and  make  constructive  and  realistic  suggestions. 
Without  adequate  documentation,   a  system  is  difficult 
to  enhance,  understand,   and  audit.     It  is  important  that 
the  auditors  insist  upon  compliance  to  documentation 
standards.     Refer  to  section  6.4.7  for  a  more  complete 
discussion  of  documentation. 
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7.4.8     Vital  Records 


During  this  part  of  the  audit  it  should  be  determined 
that  the  files,   programs,   blank  forms,   etc.,  specific 
to  this  application  have  been  incorporated  in  the  instal- 
lation's contingency  plans. 


8.      INSTALLATION  SECURITY 


8.1  Concern 

There  are  various  levels  or  rings    (see  figure  2)  of 
security  that  provide  a  good  security  posture  in  a  DP 
environment.     A  weak  control  in  any  of  these  areas  may 
lead  to  security  exposures.     The  specific  concerns 
in  this  audit  are:     1)   unauthorized  access  or  modification 
of  data,   2)   unauthorized  use  of  data  processing  resources, 
3)  misuse  of  authorized  resources. 

8.2  Purpose 

The  purpose  of  this  audit  is  to  evaluate  the  admin- 
istrative,  system  and  physical  controls  in  all  of  these 
areas  to  provide  management  with  an  assessment  of  the 
security  posture  of  the  installation  or  organization  under 
review. 

8 . 3  Approach 

In  a  multi-site  organization,   the  auditor  should  first 
select  the  installation  or  organization  with  the  greatest 
exposure.     During  the  pre-planning  stage  of  the  audit, 
the  auditor  must  carefully  describe  the  installation  under 
review  to  ensure  that  the  audit  scope  does  not  omit  any 
significant  areas  and  that  the  audit  team  is  selected  and 
prepared  for  the  unique  technical  aspects  of  the  instal- 
lation.    Whenever  possible,   team  members  possessing 
required  DP  expertise  should  be  selected.     This  not  only 
facilitates  the  audit,  but  provides  a  valuable  training 
ground  for  DP  professionals.     The  audit  approach  will  be 
a  combination  of  employee  and  management  interviews , 
documentation  reviews,  and  detail  testing  to  support  or 
disprove  interview  results.     Interviews  alone  are  not 
sufficient  without  substantive  testing. 
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Figure  2     System  Levels  of  Security 
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8.4  Scope 

The  scope  of  a  DP  installation  security  review  in  a 
large  installation  may  look  very  complex,  but  it  can  be 
divided  into  four  functional  audit  techniques: 

1)  Procedure  review 

2)  Organizational  control  review 

3)  Access  control  review 

4)  Contingency  plan  review 

It  will  be  the  intent  of  this  sub-chapter  to  identify 
all  auditable  areas  and  expand  on  only  those  that  are  not 
well  defined  in  the  literature. 

The  scope  of  this  audit  may  be  further  broken  down 
as  follows: 

Procedure  Review 

Standard  Operating  Procedures 
Self-evaluations   (performance  and  results) 


Organizational  Control 

Responsibilities 
Separation  of  Duties 
Termination  Practices 
Job  Rotation 
Vacation  Schedules 

Access  Control 

DP  Resources 

Space 

Media 

Equipment 

Programs 

Documentation 

Procedures 

Protection  Techniques 

Physical  Security,   site,  facility, 
DP  installation 
Classification  System 
Media  Control 
DP  Operations 
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Remote  Computing 
Bulk-Data  Transmission 
Program  Controls 
Encryption 

Contingency  Plan 

Emergency  Plan 
Backup  Plan 
Recovery  Plan 
Vital  Records  Plan 

8.4.1  Procedure  Review 

An  installation  security  review  should  begin  with  a 
reconciliation  of  local  procedures  with  standards  and 
guidelines.     If  local  procedures  agree  with  standards  and 
guidelines,   this  may  be  taken  as  evidence  that  the  opera- 
tion is  consistent  with  accepted  practice.     However,  the 
auditor  must  still  reconcile  actual  practice  to  accepted. 
If  local  procedures  do  not  agree  with  standards  and  guide- 
lines,  this  may  be  an  indication  that  local  management  is 
not  devoting  adequate  attention  to  DP  security. 

The  auditor  should  review  the  local  operating 
procedures  to  determine  that  they  are  adequate  and  that 
they  explicitly  define  responsibility.     In  addition,  the 
auditor  should  request  any  management  self -assessments  on 
the  subject  of  DP  security.     Concerned  management  may 
have  initiated  a  self-review  or  peer  review  program. 

8.4.2  Organization  Control 

8.4.2.1  Security  Responsibility  Assignment 

Early  in  the  review,   the  auditor  must  make  a  deter- 
mination that  responsibility  for  the  protection  of  all 
resources  has  been  explicitly  assigned.     In  addition,  each 
employee  should  have  been  assigned  responsibility  for 
protecting  resources  within  his  ownership  or  custody,  for 
noting  variances  and  for  taking  appropriate  and  timely 
corrective  action.     Where  indicated  by  the  extent  or 
sensitivity  of  resources  or  operations,   staff  responsibil- 
ity for  security  should  have  been  assigned. 

8.4.2.2  Separation  of  Duties 

Separation  of  duties  must  exist  between  DP  and  its 
users,  and  within  DP  and  its  users.     This  separation 
should  be  such  that:     1)    no  individual  has  access  to  a 
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sensitive  combination  of  resources,   2)    no  individual  is 
in  a  position  to  fail  and  conceal,   3)   each  individual's 
key  actions  are  checked  upon  by  another  individual  who 
is  only  doing  his  assigned  job  and  4)   each  individual 
can  be  held  accountable  for  his  actions. 

The  auditor  should  examine  organization  charts,  per- 
formance plans  and  such  other  evidence  of  assignment  and 
duties     as  are  used  to  determine  that  proper  separation 
has  been  provided  for.     He  should  examine  audit  trails  to 
insure  that  it  is  consistently  maintained. 

8.4.2.3     Hiring  Practices,  Job  Rotation,  Vacation  Schedules 

Other  organization  controls  such  as  these  must  also 
be  reviewed.     They  are  second  nature  to  the  auditor  and 
warrant  no  further  discussion,   except  to  say  that  they  are 
equally  important  in  the  DP  environment. 

8.4.3     Access  Control 

8.4.3.1  DP  Resources 

Access  control  to  the  site  or  facility,   the  DP 
installation,   and  all  DP  resources  must  be  reviewed.  This 
includes  space,  media,  equipment,  documentation  procedures, 
and  programs.     Techniques  for  access  control  to  some 
of  these  resources  will  be  discussed  separately.  Where 
appropriate,   the  auditor  must  determine,   from  the  DP 
installation  profile,  what  DP  resources  are  critical  and 
concentrate  the  review  efforts  there.     Logs  or  journals 
of  access  should  be  in  place  as  required  to  fix  account- 
ability.    Tests  should  be  made  to  determine  that  such 
logs  or  journals  are  routinely  reconciled  to  expectation 
on  a  timely  basis. 

8.4.3.2  Protection  Techniques 

8.4.3.2.1  Physical  Security,   Site,  Facility  DP  Instal- 
lation 

Facility  and  installation  access  control  are  the 
first  two  levels  of  protection.     Only  personnel  whose 
jobs  are  within  the  facility  or  installation  should  be 
permitted  normal  access.     All  others  should  be  admitted 
only  under  additional  rules.     The  auditor  must  test  actual 
access  to  the  authorized  list. 

8.4.3.2.2  Classification  System 

One  important  requirement  for  maintaining  access 
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control  and  other  DP  security  controls  is  the  adequacy  of 
the  system  for  identifying  sensitive  resources.     Without  a 
classification  system  for  identifying  the  relative 
importance  of  the  resources  to  be  protected,  a  DP  security 
program  will  not  be  cost  effective.     The  auditor  must  test 
the  classification  system  to  determine  that  it  is  under- 
stood and  working,   that  resources  are  being  classified 
correctly,  and  that  where  applicable,  classification 
termination  dates  are  being  assigned  and  observed. 

8.4.3.3.3  Media  Control 

In  order  to  properly  safeguard  media    (tapes,  disks, 
etc.),   it  should  be  labeled  with  its  classification  and 
each  classification  should  have  a  minimum  level  of  re- 
quired controls.     For  example,  media  labeled  "secret" 
may  be  inventoried  semi-annually  while  "top  secret" 
media  may  be  inventoried  weekly.     A  separate  access  with- 
in the  DP  installation  should  be  available  for  storing 
media.     An  authorized  access  list  should  be  available 
and  an  audit  of  access  to  media  should  be  available. 
The  auditor  may  wish  to  reconcile  the  audit  trail  of 
accesses  to  the  authorized  access  list. 

8.4.3.3.4  DP  Operations  -  Input/Output  Controls 

There  must  be  adequate  controls  to  insure: 
1)   accountability,   2)   that  only  authorized  DP  jobs  are 
processed  and,   3)    that  the  resultant  output  is  distri- 
buted to  only  the  authorized  recipients.     There  are 
numerous  ways  acceptable  for  providing  these  controls. 
Reviewing  the  DP  operations  function  for  the  presence, 
adequacy  ancl  reconciliation  of  these  controls  is  an  inte- 
gral part  of  this  audit. 

8.4.3.3.5  Remote  Computing 

Security  controls  in  a  remote  computing  or  inter- 
active environment  are  important  because  physical  locks 
and  keys  alone  may  not  provide  for  adequate  accountability 
or  deter  unauthorized  access.     The  minimum  controls  to  be 
reviewed  in  a  DP  installation  audit  include  the  following: 

User  Identification 
Data-Access  Controls 
Terminal  Identification 
System  Security  Administration 
Audit  Trails 
Terminal  Security 
Privileged  Sign-On  Codes 
Output  Controls 
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(see  Eecurj.ty  Function  Review,   chapter  9). 

8.4.3.3.6  Bulk  Data  Transmission 

Data  is  often  transmitted  in  bulk  by  mail  or 
electronically.     Depending  on  the  data  sensitivity  and/or 
classification,   certain  controls  may  be  indicated.  For 
example,    "secret  data"   to  be  forwarded  by  U .    S.   Mail  may 
require  double  enveloping  to  conceal  internal  classif- 
ication identification  and  registration  with  return  receipt 
requested. 

All  bulk  data  transmission  of  classified  data  should 
be  approved  in  writing  and  an  audit  trail  maintained 
indicating  date,    time,    sender,   approver,   recipient  and 
acknowledgment  as  appropriate. 

8.4.3.3.7  Encryption 

Enciphering  may  be  indicated  for  very  sensitive  data 
that  must  be  passed  outside  the  control  of  its  owner. 
Only  algorithms  with  known  properties  such  as  the  Data 
Encryption  Standard  algorithm  should  be  employed.  The 
implementation  of  the  algorithm  should  be  appropriate  to 
the  application.     In  reviewing  the  use  of  encryption ,  the 
auditor  should  remember  that  there  are  costs  in  terms  of 
system  performance  that  must  be  considered. 

The  auditor  must  test  to  ensure  data  is  encrypted 
where  necessary  and  that  good  encryption  procedures  in- 
cluding key  handling  have  been  implemented. 

8.4.3.3.8  Program  Controls 

Access  controls  must  also  be  in  place  to  protect 
programs,  JCL  and  related  documentation  from  unauthorized 
access.     A  program  may  be  proprietary  for  its  intrinsic 
value  or  it  may  be  "sensitive"  from  the  standpoint  that 
unauthorized  changes  could  facilitate  or  conceal  misap- 
propriation of  company  resources.     In  either  case,   it  is 
important  that  programs  and  related  JCL  and  documentation 
be  protected  from  unauthorized  access.     Controls  should 
be  adequate  for  the  integrity  of  the  change  history. 

8.4.4  Contingency  Plan 

During  this  review  the  auditor  must  determine  that 
the  installation  is  prepared  in  the  event  of  any  natural 
or  man-made  disaster  or  any  other  happening  that  would 
severely  interrupt  normal  business  operations.  The 
auditor  should  expect  to  find  plans  for  detecting  and 
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limiting  emergency  events  such  as  fires  or  intrusions 
(emergency  plan);    accomplishing  critical  jobs  on  a  timely 
basis    (backup  plan) ;    recovering  mission  capability 
(recovery  plan) ;    and  a  plan  for   identifying  and  protecting 
data  vital  to  customer,   employee,  or  stockholder  equities, 
data  related  to  national   interest    (vital  records  plan) . 

The  key  to  successful  contingency  planning  is  periodic 
testing.      It  can  reasonably  be  assumed  that  a  contingency 
plan  will  not  be  effective,    if   it  is  not  tested  and  up- 
dated annually.     The  area  of  contingencies  should  not  be 
left  to  chance.     The  auditor   should  look  for  evidence  that 
the  plan  has  been  both  tested  and  updated. 


9.      SECURITY  FUNCTION  REVIEW 


9.1  Concern 

The  security  department  or  function  provides  for  the 
articulation  of  security  policy,   the  allocation  of  securi- 
ty resource,   the  definition,  communication,  and  adminis- 
tration of  security  rules,   the  timely  recognition  of 
variances,  and  the  recommendation  of  corrective  action. 
It  is  a  staff  function  serving  all  levels  and  functions 
of  management.     Depending  on  the  nature  and  scope  of  the 
system  it  supports,   this  function  may  be  responsible  for 
extensive  computerized  data  and  procedures  for  carrying 
out  its  responsibilities.     Its  data  may  include  state- 
ments of  authorization,    system  or  application  access 
rules,   and  notices  of  variances.     Its  procedures  may 
include  programs  for  applying  or  maintaining  access  rules, 
or  for  communicating  or  analyzing  present  rules  or 
notices  of  variances  from  them. 

This  staff  is  responsible  for  the  implementation  and 
operation  of  all  security  controls  that  are  generalized 
across  applications  and  operations.     It  may  be  viewed  as 
a  vendor  of  access  control,  monitoring  and  advisory 
service  to  applications,  and  as  a  vendor  to,  and  customer 
of,  operations. 

The  proper  functioning  of  this  department  or  staff, 
and  the  integrity  of  its  data  and  programs,  may  be  vital 
to  the  uniform,  timely  and  consistent  application  of  all 
security  controls  and  procedures. 

9.2  Purpose 


The  purpose  of  the  security  function  review  is  to 
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insure  that:      its  facilities  and  organization  are  consis- 
tent with  good  practice  and  the  needs  of  the  installation 
and  applications;    its  resources  are  consumed  as  manage- 
ment intends  and  that  using  departments  are  receiving 
satisfactory  service;    that  its  actions  are  consistent  with 
management  and  using  department  authorization;   that  its 
audit  trail  is  adequate  to  demonstrate  authorization, 
accountability,   accuracy  and  completeness;   and  that  vari- 
ances are  dealt  with  on  a  timely  basis. 

This  review  is  indicated  whenever  significant  security 
functions  or  services  are  generalized  across  using  depart- 
ments or  applications  such  as  in  time-sharing,  data-base, 
or  interactive  environments. 

9 . 3  Approach 


Depending  on  the  size  of  the  installation  or  system 
to  be  audited,  a  review  of  the  security  function  may  be 
a  module  of  another  audit    (e.g. ,  a  DP  installation  audit) 
or  it  may  be  done  as  a  stand-alone  audit.     Security  may  be 
viewed  as  an  application  and  audited  accordingly  (see 
Application  Review,  chapter  7) .     The  same  audit  approaches 
and  techniques  should  be  used  in  this  audit  as  discussed 
in  the  prior  audits. 


9.4  Scope 


An  outline  of  the  scope  of  this  audit  is  as  follows: 
General 


Responsibility  Definition 

Standard  Operating  Procedures/Users  Manuals 
Self-Reviews  of  DP  Security 
Education 
Employee  Awareness 

Security  Administration  (Interactive) 

Administering  Security  Codes 

Monitoring 

Reporting 

Violation 

Critical  Transaction  Usage 
Terminal  Authorization 
User  Authorization 
User  Termination 
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Access  Control 


DP  Resources 
Space 
Media 
Equipment 
Documentation 
Communications 

Contingency  Plans 

Emergency  Plan 

9.5  General 

9.5.1  Responsibility 

The  security  function  is  generally  a  staff  function 
responsible  for  overseeing  and  monitoring  DP  security. 
The  auditor  must  ensure  that  this  function  has  been 
clearly  defined. 

The  security  function  serves  user  management  by 
administering  access  rules  within  the  system.     The  auditor 
should  look  for  adequate  audit  tools  to  ensure  all  admin- 
istrative activity  is  as  authorized. 

9.5.2  Standard  Operating  Procedures/Users  Manuals 

It  is  the  responsibility  of  the  security  function  to 
ensure  local  security  guidelines,  operating  procedures 
and  users  manuals  are  written  and  properly  maintained.  The 
auditor  should  review  these  documents,  as  indicated,  and 
test  for  currency. 

9.5.3  Self-Reviews  or  Peer  Reviews 

The  auditor  should  request  the  results  of  any  self- 
reviews  or  peer  reviews  on  the  subject  of  DP  security 
and  the  corresponding  action  plans  and  progress  to  date. 
An  analysis  of  self-review  information  will  give  the 
auditor  a  good  insight  into  the  organization  and  problems 
identified,  but  does  not  relieve  him  of  the  responsibility 
to  complete  the  audit.     The  auditor  may,  and  should,  use 
the  results  of  the  self-reviews  where  applicable  in  his 
final  report  as  long  as  the  source  of  the  information  is 
acknowledged  and  the  resulting  comments  are  put  in  proper 
perspective . 
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9.5.4  Education 

It  may  be  the  responsibility  of  the  security 
function  to  both  conduct  tailor-made  education  courses 
for  the  line  functions  and  to  ensure  that  these  func- 
tions take  full  advantage  of  all  applicable  security 
courses  on  DP  security.     Evidence  of  the  performance 
of  such  responsibility,   including  class  schedules, 
syllabus,  and  rosters,   should  be  reviewed. 

9.5.5  Employee  Awareness 

This  is  perhaps  the  most  important  aspect  of  the 
security  function's  job.     Because  the  subject  of  DP 
security  may  be  viewed  as  negative,   the  auditor  must 
determine  what  the  security  function  is  doing  to  make  it 
positive  and  to  maintain  employee  awareness  and  concern. 
The  possibilities  in  this  area  are  limitless.  Posters, 
suggestion  programs,   informal  awards,  breakfasts,  lunch- 
eons, guest  speakers  and  executive  management  speeches  are 
only  a  few  of  the  possible  ideas.     Instead  of  guards  only 
noting  violations,  they  could  leave  a  thank  you  note  for 
securing  proprietary  data.     The  content  of  the  awareness 
program  might  point  out  the  value  of  assets  and  the 
importance  of  the  employees'   role  in  protecting  them. 

In  any  event,   this  is  an  important  area.     An  effective 
DP  security  program  is  not  possible  without  the  concern 
and  commitment  of  the  employees. 

9.6     Security  Administration   (Interactive  Environment) 

Generally,   in  any  interactive  system  someone,  or  a 
group,   in  a  staff  capacity  has  been  designated  the  security 
administrator.     The  proper  performance  of  the  associated 
responsibilities  is  important  to  maintaining  effective 
system  security.     The  responsibilities  of  a  security 
administration  may  include: 

Authorizing  use  of  system  resources 
Administering  security  codes 
Monitoring  user  activity 

Violations  or  variances 

Critical  transaction  usage 
Terminal  authorization 
User  authorization 
Data  access  control 
User  security  education 
Contingency  plans 
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The  auditor  must  test  the  security  administrator's 
performance  in  all  of  these  areas.     The  auditor  should 
expect  to  find  written  evidence  to  support  the  proper 
execution  of  these  tasks . 

An  area  of  the  security  administrator's  responsibility 
that  is  often  overlooked  is  user  involvement.     The  security 
administrator  should  motivate  user  involvement,  under- 
standing, and  perhaps  most  important,  feedback.  The 
security  administrator  should  continually  review  user 
security  practices. 

9.7  Access  Control 

In  this  audit  the  security  administrator's  role  in 
access  control  or  the  monitoring  of  access  control  must  be 
evaluated.     Refer  to  section  6.4.3  for  more  detail.  The 
security  administrator  is  generally  responsible  for 
advising  management  of  any  control  deficiency. 

9.8  Contingency  Plan 

The  security  administrator's  role  in  creating,  imple- 
menting, and  evaluating  contingency  plans  should  be 
reviewed.     Refer  to  chapter  8.4.4.      The  auditor  should 
insure  that  proper  treatment  of  the  security  function  is 
included  in  all  contingency  plans. 

9 . 9  Summary 

The  security  administrator's  job  may  be  viewed  as 
writing  security  procedures,  implementing  them  and  then 
reviewing  compliance.     Any  control  deficiencies  noted 
during  a  security  audit  are  a  direct  reflection  on  the 
security  administrator's  job  performance,  unless  they  had 
been  previously  noted  and  escalated  to  the  right  level  of 
management  for  resolution. 


10.      CONTROLLED  TESTS/PENETRATION  STUDY 


10.1  Concern 

The  purpose  of  this  audit  is  to  resolve  fundamental 
and  recurring  problems  and  exposures  that  auditors  have 
continually  pointed  out  to  management  that  have  not  been 
resolved.  Because  of  the  types  of  problems  noted  in 
chapter  3,  it  often  happens  that  management  does  not  pay 
attention  to  the  auditor's  concern.  Management  may  have 
an  attitude   such  as,   "it  can't  happen  to  me". 
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10.2  Purpose 


The  purpose  of  this  test  is  to  dramatize  to  the 
executive  management  the  need  for  DP  security  by  per- 
petrating an  unauthorized  act. 

10.3  Approach 

The  auditor  may  use  his  knowledge  of  DP  control 
exposure,   but  should  not  use  audit  privilege.     At  the 
successful  completion  of  the  test,  the  auditor  must  be 
able  to  demonstrate  beyond  the  shadow  of  a  doubt  that  the 
compromise  could  have  been  perpetrated  by  another 
employee  or  an  outsider.     The  auditor  must  be  able  to 
prove  audit  privilege  was  not  a  factor. 

The  chance  of  success  for  an  undetected  compromise 
should  be  better  than  90%,   since  if  the  attempted 
compromise  is  discovered,  the  opposite  effect  of  what 
was  intended  will  be  accomplished,  not  to  mention  embar- 
rassment to  the  auditor. 

Such  a  compromise  plan  should  be  enacted  only  with 
the  concurrence  of  audit  and  executive  site  management. 
The  test  must  be  controlled  to  prevent  the  auditor  from 
being  put  in  a  situation  where  he  could  perpetrate  a 
real  fraud  without  detection. 

The  group  concluded  that  this  is  an  effective,  but 
dangerous  approach  that  should  be  well  controlled  and 
carefully  planned  as  a  last  resort. 

It  is,  however,  a  highly  effective  technique,  when 
done  in  a  truly  professional  manner. 

10.4  Scope 

The  scope  in  this  situation  is  limited  only  by  the 
individual's  imagination.     The  following  areas  represent 
possibilities  for  a  penetration  study.     Each  of  these 
potential  areas  will  be  discussed  briefly  on  the  following 
pages.     Any  penetration  study  is  unique  to  the  environ- 
ment and  must  be  assessed  on  its  own  merits: 

1)  Application  programming 

2)  DB/DC  systems 

3)  Information  security 

10.4.1     Application  Programming 

Assign  an  EDP  auditor  to  application  programming  with 
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the  instructions  to  attempt  to  perpetrate  a  fraud  without 
detection  by  manipulating  program  code.     The  application 
to  be  selected  should  present  a  high  probability  of 
success   (e.g./  payroll).     This  approach  is  equally  appli- 
cable to  a  batch  or  an  interactive  environment. 

10.4.2  Data  Base/Data  Communication  Environment 

Either  by  posing  as  a  user  or  actually  working  in  a 
sensitive  user  area,  the  auditor  should  attempt  to  bypass 
system  and  administrative  controls  in  an  undetected 
manner  to  misappropriate  company  assets.     This  approach 
generally  requires  expending  enough  time  to  thoroughly 
understand  the  application  and  surrounding  controls. 

10.4.3  Information  Security 

This  approach  is  applicable  where  the  information 
itself  is  highly  proprietary   (e.g.,  research  and  develop- 
ment environment) .     The  purpose  is  to  bypass  controls 
and  obtain  highly  proprietary  company  data  in  an  undetec- 
ted manner.     The  same  approach  can  be  used  to  prove  the 
vulnerability  of  this  data  to  unauthorized  modification 
or  destruction.     A  simple  and  effective  application  of 
this  approach  might  include  an  auditor  making  after 
hours  tours  in  terminal  rooms  looking  for  a  password 
and/or  a  user's  manual  carelessly  left  behind.  Subse- 
quent access  attempts  from  a  remote  terminal  using  the 
user's  manual  and  sign-on  password,  will  more  than 
likely  yield  interesting  results  and  prove  the  need  for 
greater  security. 

The  key  to  this  approach  is  to  obtain  undetected 
access  to  important  information  while  being  unauthorized, 
and  by  not  using  audit  privilege.     Being  able  to  demon- 
strate that  anyone   (employee  or  cleaner) ,  who  has  access 
to  the  building,  could  have  obtained  unauthorized  access 
to  the  information  is  key. 

10.4.4  Summary 

Unauthorized  penetrations,  while  unorthodox,  are 
valuable  ways  to  demonstrate  the  auditor's  concerns  to 
management,  when  those  concerns  are  fundamental,  recurring, 
and  are  not  getting  management  action.     However,   they  re- 
quire extensive  planning,   and  sometimes,  relatively 
extensive  devotion  of  resources  with  no  guaranteed  pay- 
back.    Penetration  attempts  are  also  risky  and  prove  the 
auditee's  rather  than  the  auditor's  case,   if  unsuccessful.. 
This  is  not  to  mention  the  possibility  of  loss  of  credit- 
ability  . 
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11.      ISSUES  FOR  THE  COMMUNITY 


The  working  group  concluded  that  there  are  at  least 
three  issues  to  which  the  data  processing  community  must 
address  itself  in  the  coming  years.     These  issues  can  be 
expected  to  have  a  significant,   if  uncertain  effect,  on 
the  security  and  auditability  of  systems.     They  are  the 
implications  of  technology  advances,  adequacy  of  the 
literature,   and  the  state-of -the-practice  of  data 
processing. 

11.1     Implications  of  Future  Technology 

There  are  several  directions  that  are  evident  in  the 
technology  that  can  be  expected  to  affect   the  security 
and  auditability  of  data  processing  in  the  future.  These 
include  the  increasing  density  and  portability  of  media, 
mass  storage,  and  distributed  systems. 

As  the  density  with  which  we  can  record  information 
on  media  increases,   the  portability  of  the  data  goes  up. 
This  means  that  the  exposure  of  the  data  to  theft  or 
conversion  will  also  increase.     At  the  same  time,  smaller 
volumes    (e.g.,   cartridges  for  the  IBM  Mass  Storage  System)* 
are  being  introduced.     Large  quantities  of  data  can  be 
recorded  on  volumes  small  enough  to  be  easily  secreted 
on  a  person. 

This  tendency  is  offset  in  part  by  the  introduction 
of  mass  storage  systems  which  enable  us  to  move  even 
larger  quantities  of  data  inside  the  control  domain  of 
the  hardware.     The  effects  of  this  will  include  a  reduc- 
tion in  manual  intervention  with  the  concomitant 
opportunity  for  error,  and  an  increase  in  the  uniformity, 
consistency,  and  timeliness  of  control.     However,  since 
more  and  more  data  will  be  subject  to  a  single  event, 
data-base  back-up  procedures  will  become  increasingly 
important . 


*Editor's  Note:     Other  small  volume  storage  devices  exist 
in  the  marketplace.     The  identification  of  this  particular 
one  does  not  imply  recommendation  or  endorsement  by  the 
National  Bureau  of  Standards. 
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Distribution  of  systems  over  geography  will  reduce 
the  amount  of  resource  subject  to  a  single  event.  It 
can  be  expected  to  reduce  communication  cost  and  improve 
response  time.     On  the  other  hand,   it  cannot  be  expected 
that  management  control  will  be  as  uniform  or  as  effective 
over  a  distributed  system. 

Obviously,   some  of  these  technical  directions  are 
inherently  positive.     All  can  be  dealt  with  given  proper 
attention.     It  was  the  sentiment  of  the  working  group 
that  management  needs  to  be  alerted  to  the  implications 
and  possibilities  of  these  technology  advances. 

11.2     Adequacy  of  the  Literature 

It  was  the  consensus  of  the  group  that  the  liter- 
ature for  auditing  data  processing  security  is  adequate 
in  the  sense  that  everything  is  written  down  somewhere. 
As  might  be  expected  in  a  new  discipline,   the  literature 
suffers  from  style  and  orientation,   lack  of  audience 
sensitivity,  volume,  and  absence  of  authority. 

The  style  and  orientation  of  the  literature  often 
obscures  its  content.     Organization  and  structure  is 
different  for  each  source.     Reference  is  seldom  made  to 
models  or  structures  used  in  other  sources.     Not  only  does 
this  make  it  difficult  to  relate  material  from  separate 
sources,  but  it  makes  it  almost  impossible  to  test  any 
source  for  completeness. 

Emphasis  is  often  placed  upon  examples,  implemen- 
tations and  procedures,  rather  than  on  objectives, 
principles  and  guidelines.     This  places  the  responsibility 
for  identifying  and  articulating  objectives  and  principles 
on  the  reader.     It  dates  the  material  and  obscures  its 
applicability  to  new  media  or  technology. 

Most  of  the  material  in  this  area  is  written  for 
managers  rather  than  auditors.     Often  this  makes  the 
material  less  useful  to  the  auditor.     Some  material  is 
designed  to  attract  the  largest  possible  audience.     It  can 
hardly  be  expected  to  serve  anyone  well.     Even  that 
material  which  is  designed  specifically  for  auditors 
may  not  say  so,   so  that  even  the  material  which  is  useful 
and  appropriate,  may  be  difficult  to  find. 

There  is  a  plethora  of  data  being  published.  While 
this  may  not  appear  at  first  glance  to  be  a  problem, 
it  places  upon  the  reader  a  requirement  to  sort  the 
readable,  useful  and  applicable  from  the  other  ninety 
percent.     This  process  is  complicated  by  the  fact  that  the 
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credentials,   experience  and  claims  to  authority  of  the 
author  are  frequently  inadequate  or  unknown. 

The  working  group  felt  that  there  is  a  need  for  a 
single  compendium  produced  by  a  reputable  and  authori- 
tative institution.     This  reference  should  be  developed 
with  auditor  involvement.     It  should  stress  objectives 
and  alternative  solutions.     The  group  also  saw  a  need  for 
the  same  material  to  be  covered  several  times,  or  at  least 
cross-referenced,   once  for  each  of  the  involved  audiences. 

11.3     State-of -the-Prac tice 

The  working  group  was  extremely  critical  of  the  state- 
of  -the-practice  in  data  processing.     Much  of  what  appears 
to  be  audit  or  security  problems  in  data  processing  is 
in  reality  the  institutionalization  of  bad  practice. 
While  this  bad  practice  may  not  be  serious  or  risky  in 
operations,   it  is  extremely  serious  in  systems  develop- 
ment. 

This  problem  was  seen  by  the  group  as  a  management 
failure  rather  than  a  technical  problem.     Managers  are 
seen  as  controlling  process  and  schedule  while  neglecting 
product  and  quality. 

Today's  inadequate  practice  is  seen  as  resulting  from 
tradition  and  inertia,   from  the  effect  of  the  tools,  and 
from  a  perception  on  the  part  of  managers  that  programmers 
are  resistant  to  change.     Today's  practice  is  the  result 
of  the  brief  history  of  programming.     Half  of  that 
history  was  spent  in  relatively  slow  and  expensive  machines 
that  worked  on  one  job  at  a  time.     The  practice  that  was 
appropriate  for  those  machines  is  inadequate  for  today's 
resource-sharing  systems. 

Managers  appear  to  be  reluctant  to  introduce  new 
control  because  they  fear  that  programmers  will  resist 
any  change  to  the  way  they  do  their  jobs.     It  is  ironic 
that  a  technology  whose  success  depended  upon  its  ability 
to  get  its  users  to  accept  change,   is  now  threatened  by 
the  reluctance  of  its  practitioners  to  accept  change. 

The  working  group  was  unanimous  in  its  conclusion 
that  data  processing  management  must  move  with  all 
deliberate  haste  to  improve  the  state-of-the-practice  in 
programming  application  development  and  system  develop- 
ment.    They  must  implement  all  of  the  so-called  "improved 
programming  technologies" .     They  are  reminded  that  these 
techniques  are  in  reality  management  tools  and  not 
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programming  tools.     As  such,   they  must  be  implemented 
by  managers  and  not  programmers. 

The  use  of  the  new  management  techniques  will  require 
and  will  be  facilitated  by  the  development  of  new  tools 
to  support  programmers.     These  new  editors,  compilers,  and 
library  managers  must  support  the  role  of  managers  in 
authorizing,   naming,   reviewing  and  reconciling  programs. 
They  must  be  restrictive  and  controllable  as  opposed  to 
permissive  and  flexible. 

It  was  suggested  that  programmers  are  not  as  resis- 
tant to  change  as  their  management  perceives  them.  They 
are  at  least  as  flexible  as  their  users.     Like  their  users 
they  will  respond  and  adapt  to  new  management  expectations 
and  improved  tools. 

The  most  urgent  item  on  the  agenda  of  the  data  proces 
sing  community  is  to  learn  to  build  auditable  systems  in 
an  auditable  way. 
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EDITORS'  NOTE 


A  brief  biography  of  the  Session  Chairperson  follows: 

Clark  Weissman  is  Deputy  Manager,  Research  and  Development  Division 
and  Chief  Technologist  with  System  Development  Corporation.    He  is 
responsible  for  the  corporation's  Independent  Research  and  Development 
(IR&D)  program.    During  his  twenty  years  with  SDC  he  has  led  the  corpo- 
ration into  a  number  of  advanced  technology  areas,  including  programming 
language  technology,  operating-system  design,  time-sharing,  and  computer 
system  security.    His  paper,  "Security  Control  in  the  ADEPT-50 
Time-Sharing  System,"  which  was  named  the  outstanding  paper  at  the  1969 
API  PS  Fall  Joint  Computer  Conference,  is  one  of  the  original  early 
contributions  to  the  theory  and  methodology  of  computer  system  security. 
For  three  years  he  managed  SDC's  Systems  Security  Department.  He 
directed  a  large  number  of  security-penetration  analyses  for  nearly  all 
commercial  computer  systems  and  a  study  for  the  National  Bureau  of 
Standards  on  applications  of  the  NBS  data-encryption  standard.  Earlier, 
he  directed  the  corporation's  ARPA-sponsored  research  and  development 
activities,  which  included  several  studies  relating  to  the  design  and 
applications  of  computer  networks.    He  holds  a  degree  in  aeronautical 
engineering  (Massachusetts  Institute  of  Technology,  S.B.).    He  is  the 
author  of  the  1967  LISP  1 .5  Primer,  also  published  in  a  Japanese  edition 
in  1970.    He  is  listed  in  Who's  Who  in  the  West,  and  has  been  active  in 
the  ACM,  being  a  past  Editor  of  the  OS  Department  of  ACM. 


The  charge  given  to  this  session  was: 

PROGRAM  INTEGRITY:    What  are  the  audit  approaches  and  techniques 
for  evaluation  of  program  integrity  in  an  ADP  environment?  In- 
clude consideration  of  operating  systems,  data  base  management 
systems,  and  application  programs. 

Program  integrity  has  been  defined  as  that  state  in  which  the 
software  is  logically  complete,  and  correctly  and  consistently  performs 
the  task  for  which  it  was  designed  and  no  more.    It  is  within  this 
context  that  this  session  should  consider  the  problems  associated  with 
evaluation  of  program  integrity. 

This  session  is  to  identify  the  audit  approaches  and  techniques 
currently  available  or  needed  that  would  produce  an  effective  evaluation 
of  (1)  the  controls  exercised  by  management  to  ensure  program  integrity 
during  software  development,  and  (2)  the  operational  reliability  and 
performance  assurance  of  software  design  and  implementation. 


The  consensus  report  that  follows  was  developed  and  reviewed  by 
the  entire  membership  of  this  session. 
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Program  Integrity  Assessment 
A  Concensus  Report 


Clark  Weissman 


1.    WHAT  IS  PROGRAM  INTEGRITY? 


Coming  to  grips  with  program  integrity  requires  definition  and 
assessment  of  both  terms--program  and  integrity.  In  the  broadest 
sense,  a  program  is  synonymous  with  a  system  of  programs  and  includes 
control  software,  operating  systems,  data  base  management  systems,  or 
applications  programs.  Furthermore,  programs  are  "organic"  in  that 
they  exist  in  different  forms  throughout  their  life  cycle,  from 
requirements,  specifications  and  design,  to  source  and  object  code. 


Integrity  concerns,    foremost,    (1)    the    correctness    with    which  the 

program  satisfies  its  requirements,  implements  its  specifications,  and 

does  nothing  else.    But  integrity  concerns  more  than    correctness.  It 

also  relates  to  (2)  satisfying  a  trained  user's  expectations  of 
program  behavior  and  to    (3)  being  useful    in    fulfilling    an  intended 

mission.    Furthermore,  integrity  requires  that    (4)  the  program  can  be 

evaluated  to  establish  a  level  of  trust  in  it.  All  four  aspects  of 
integrity  must  hold  over  the  full  life  cycle  of  the  program. 


System  integrity  is  a  function  of  the  integrity  of  the  program  parts. 
Usually  system  integrity  is  lov/er  than  the  integrity  of  its  component 
programs;  however,  if  redundant  independent  modules  are  employed  to 
check  one  another's  computation,  system  integrity  can  be  somewhat 
higher  than  the  integrity  of  the  component  programs. 


In  summary,  program  integrity  will  require  management  to  judge  the 
risks  of  accepting  a  level  of  integrity  for  the  given  threat 
environment.  These  factors  in  assessing  program  integrity  in  the 
context  of  risk  are  expanded  in  the  balance  of  this  section.  The 
issues  presented  form  a  consensus  of  the  session  participants. 
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2.    A  CONTEXT  FOR  PROGRAM  INTEGRITY 


Security  of  a  computer  system  increases  with  a  reduction  in  (1) 
system  flaws,  (2)  exposure  of  system  assets,  and  (3)  exploiters.  All 
protection  strategies  pursue  these  goals.  Program  integrity  addresses 
only  the  first  goal--flaw  reduction. 


However,  management  can  make  choices  in  its  protection  strategy  to 
trade  reductions  in  integrity  for  improvement  in  the  other  goals  to 
reach  a  balance  for  a  given  threat  or  budget  level.  The  issues 
associated  with  integrity  are  discussed  below. 


2.1    Programs  Change  With  Time  (Life  Cycle) 


We  normally  think  of  programs  in  their  final  code  or  operations 
stage.  Program  integrity,  however,  must  be  built  into  programs  from 
the  beginning  of  their  development.    Programs  move  through  six  stages. 

1.  Org  an i  z  at ion  Mission:  The  purpose  of  the  system  is  defined, 
ana  respdnsi"BTTi  ti  es  are  divided  among  the  component 
organizations . 


2.  ^e^Li i'^.^.n^snts :  Mission  responsibilities  are  translated  into 
specific  system  requirements;  i.e.,  vjhat  is  to  be  done. 
Functions,  performance,  cost,  and  otherTTfni ts  are  defined. 


Specifications:  Requirements  are  translated  into  system 
spec iTi caTi on" s  for  each  system  element--hardware,  software, 
communications,  people,  facilities.  Specifications  define  in 
detail  how  requirements  will  be  met.  Specifications  exist  at 
the  functional  level  and  at  the  component  level.  For  the 
software  component,  they  are  called  "coding  specs."  Various 
schemes  exist  for  documenting  coding  specs,  including  flow 
diagrams,  decision  tables,  table  and  memory  layouts, 
mathematical  algorithms,  Parnas-like  modules,  and  most 
recently,  formal  specification  languages. 
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4.  Code :  Specifications  are  translated  into  source  code  in  some 
popular  programming  language,  e.g.,  PASCAL,  PL/1,  FORTRAN, 
COBOL,  or  machine  assembly  language,  and  further  translated 
into  run-time  object  code  or  micro-code  by  language  compiler 
or  assembly  tools. 


^'  Jest  and  ,Intec[rati_on :  Before  programs  are  placed  into 
production  They  are  tested  individually  and  as  part  of  the 
total  integrated  system.  This  step  is  performed  in  addition 
to  the  normal  "unit"  testing  and  "debugging"  by  the 
programmer  of  the  original  code. 


^'  Op e r a t i 0 n s  a n d  Maintenance  ( 0& M ) :  Libraries  of  source  and 
oB'ject  code  programs""are  ~  stored  for  use  in  the  computer 
facility.  From  time  to  time,  minor  changes  are  made  to  these 
programs  by  the  O&M  staff  to  correct  errors,  improve 
performance,  expand  functions  and  capabilities,  or  adapt  to 
new  equipment.  Control  of  these  changes  is  part  of  O&M 
Configuration  Management.  O&M  can  get  out  of  hand,  and 
program  integrity  can  suffer,  if  major  program  redesign  or 
modification  is  attempted  at  this  stage.  Major  program 
changes  must  be  viewed  as  new  software  that  will  replace 
existing  modules,  and  these  new  modules  should  be  contracted 
for  as  were  the  original  programs,  beginning  at  the  mission 
and  requirements  life-cycle  stages. 


2.2    Visiblity  of  Relationships  Is  Lost  Betvjeen  Stages 

One  of  the  more  significant  program  integrity  problems  that 
results  from  this  staging  of  software  production  is  the  loss,  as 
complexity  and  detail  increase,  of  visible  links  between  the  stages. 
For  example,  seldom  is  it  possible  to  directly  relate  a  module  of  code 
back  to  the  mission  goal,  or  system  requirement,  or  even  the 
functional  specification.  Somehow,  the  connection  gets  lost  as 
functions  are  distributed,  level  notations  are  translated  to 
lower-level  languages,  and  programs  are  made  to  serve  multiple 
requirements. 


This  loss  of  the  thread  between  the  initial  requirement  and  the 
resulting  code  becomes  serious  v;hen  code  must  be  changed  for  any 
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purpose.  The  more  significant  the  modification,  the  greater  is  the 
need  for  comprehending  the  interrelations  of  the  parts  toward 
satisfying  the  mission  requirements.  Code  patching  is  a  major  cause 
of  integrity  loss,  for  the  "tactical"  fix  often  undermines  an  unseen 
"strategic"  mission  design,  leading  to  even  larger  problems. 


2.3    Program  Integrity  Assessment  is  Multi-dimensional  Problem 


Determining  when  to  audit  and  evaluate  in  the  life-cycle 
metamorphosis  of  a  program  is  but  one  dimension  of  the  integrity 
assessment  problem.  Other  dimensions  include  the  relevance  and 
severity  of  the  security  threat  and  the  methods  employed  during 
development  to  achieve  integrity.  These  dimensions  are  treated  more 
fully  in  the  following  sections. 


3.    RELEVANT  THREATS  AND  THEIR  SEVERITY 


Threats  result  from  nature  and  from  man.  The  effects  of  natural 
disasters,  physical  breakdowns,  and  human  error  (by  builder  or  user) 
can  be  predicted  in  service  interruption  or  accidental  information 
disclosure.  More  insidious  are  the  threats  from  motivated  human 
interlopers.  We  further  divide  the  human  threat  into  casual  and 
deliberate  attacks.  The  former  group  deals  with  individuals  who 
stumble  on  a  flaw  or  actively  browse  and  seek  f 1 aws  they  can  exploit. 
The  latter  group  is  more  sophisticated  in  resources,  planning,  and 
methods  of  attack.  These  deliberate  attack  threats  are  carefully 
planned  by  a  conspiracy  team  that  creates  flaws  by  modifying  running 
code  or  planting  subversive  "trapdoor"  functions  in  the  system, 
application,  or  library  programs.  Possibly  the  worst  deliberate 
threat  is  from  an  irrational  attack  by  a  disgruntled  employee.  Since 
the  normal  behavior  constraints  on  the  attacker  ~  exposure  and 
capture  or  expectation  of  gain  --  are  absent  or  distorted,  the 
irrational  attack  cannot  be  thwarted  by  most  countermeasures . 


Ranking  these  threats  by  the  severity  of  the  attack  and  sophistication 
of  the  needed  countermeasures  (high-to-low),  produce  the  following 
list: 
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1.  IRRATIONAL  ATTACK 

2.  CONSPIRACY  TEAM 

3.  BROWSER 

4.  STUMBLER 

5.  HUMAN  ERROR 

6.  NATURAL  FAILURE 


4.    METHODS  FOR  ACHIEVING  PROGRAM  INTEGRITY 


It  was  established  by  consensus  of  the  session  that  program 
integrity  requires  the  program  to  be  £orrect,  robust,  and 
trustworthy.  A  correct  program  provides  evidence  "that  Tt"  satisfies 
its  mission,  requirements,  and  specifications.  By  analogy  to  the 
auditing  of  a  corporation,  the  audit  of  a  program's  correctness 
requires  evidence  equivalent  to  the  corporation's  "financial 
statement ." 


A  robust  program  includes  mechanisms  to  maintain  adequate  levels  of 
performance  in  the  face  of  unexpected  behavior  in  the  environment,  as 
will  occur  from  user  keystroke  or  procedural  program  flaws,  operator 
goofs,  etc.  The  corporate  audit  analog  for  these  robust  mechanisms  is 
the  "internal  financial  control  system." 


A  trustworthy  program  is  one  that  is  well  documented,  functionally  not 
complex,  modular,  relatively  short  in  length,  integrated  into  a 
rigorously  structural  architecture,  and  produced  as  the  result  of  good 
programming  practices  and  sensible  standards.  The  trustworthiness  of 
programs  is  the  corporate  analog  of  having  "generally  accepted 
accounting  principles." 


4.1    Evidence  of  Correctness 


Program  validation  and  verification  (V&V)    can    be    either  static 
(done  on  the  source  code)  or    dynamic    (done    on    the    running  object 
code) . 
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4.1.1    Static  Evaluation 


Combinations  of  the  following  source  code  examination  approaches 
are  currently  being  used  by  industry  or  R&D  laboratories: 


2£ll9.1  '^^^^    method    entails    a    formal    meeting  of 

desfgners  wTth  reviewers  (not  associated  with  the 
deliverable)  to  scrutinize  the  product  design  against  mission 
and  requirements.  The  product  design  should  include 
narrative  documents,  logic  diagrams,  and  functional  and 
coding  specifications.  It  may  include  source  code  for 
critical  components.  Design  reviews  should  be  scheduled 
milestones  for  each  subsystem  and  major  component.  Results 
must  be  documented  and  communicated  to  all  participants. 


^-  '^^^  classical  scientific    method    is    to  invite 

interested  professional  peer  review  and  comment  on  the 
product  at  various  stages  of  program  life  cycle.  Design 
review  is  one  important  instance  of  peer  review. 


3.  Qual  i ty^  ,'^9.'2^C2l  .19,^1'  ^  third  party  (neither  customer  nor 
3'eveToper7" "i's"'  committed  to  check  the  quality  of  all 
deliverables  during  product  life  cycle.  This  technique 
combines  1  and  2  above  in  a  formal,  often  contractual 
manner.  The  QC  contractor  is  selected  because  of  its 
experience,  tools,  personnel,  and  skill  in  such  v;ork. 

^'  9-'^i!jPil^'^ .  ^,*].^.'-'*^J'^g'  Source-code-to-object-code  translators 
(iTe . ,  com'pTTer sT~ h ave  alvyays  been  used  to  detect  program 
errors  as  a  QC  tool.  R&D  has  suggested  new  emphasis  on  this 
technique  as  a  mechanism  for  enforcing  good  programming 
practice.  New  languages  demand  explicit,  detailed 
declarations  of  a  programmer's  intent  with  strong  data 
typing,  restricted  program  scopes,  rigid  module  calling 
sequences,  etc.,  that  force  structured  programming.  The 
compilers  for  these  languages  do  extensive  and  complete 
checking  to  enforce  the  language  syntax  and  semantics,  and  in 
some  cases  generate  code  for  run-time  enforcement  of  program 
assertions . 
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^-  .^^ly^y.^-    ^    number    of    source-code    tools  are 

avaf  TalDTe""  tin  at  perform  some  of  the  syntax  and  semantic 
analysis  of  a  compiler,  but  do  not  generate  object  code. 
Such  tools  are  used  to  produce  flow  diagrams,  reformat  code 
to  aid  documentation,  produce  cross-reference  listings  and 
indices  for  improved  library  control  and  use,  and  to  produce 
test  cases  for  dynamic  evaluation.  Newer  uses  are  to 
automatically  generate  truth  assertions  about  the  program  to 
assist  in  the  formal  proof  of  correctness. 


6.  ^'2"]ll  ii''",9L9..t! •  Formal  proof  of  program  correctness  is  the 
leading  edge  of  the  state-of-the-art.  Basically,  the  method 
accepts  "correctness  criteria"  and  the  "program"  as  input  and 
produces  as  output  a  formal  proof  (or  counter  example)  that 
the  program  satisfies  the  correctness  criteria.  In  practice, 
the  technique  is  iterative  at  each  life-cycle  stage.  At  the 
top  level,  the  correctness  criteria  are  a  set  of  truth 
assertions  and  mathematical  models  of  program  requirements, 
and  the  program  is  a  mathematical  specification,  both 
expressed  in  a  "specification  language."  At  the  lowest 
level,  the  correctness  criteria  are  the  prior  level's  output 
specifications,  and  the  program  is  the  Higher  Order  Language 
(HOL)  source  code.  At  each  level,  these  inputs--criteria  and 
program--are  processed  through  a  "Verification  Condition 
Generator,"  which  produces  a  set  of  conditions  to  be 
verified.  The  "verification  conditions,"  e.g.,  source 
program  and  truth  assertions,  are  processed  by  a  "Theorem 
Prover"  producing  a  formal  mathematical  proof  of 
correctness--  i.e.,  a  proof  that  the  source  program  satisfies 
the  truth  assertions.  The  process  can  be  manual  or 
automated.  A  number  of  quite  restricted  "programs"  have  been 
proved  both  manually  and  with  automated  aids,  leading  to 
encouraging  optimism.  However,  the  problems  are  great  and 
not  fully  understood,  the  progress  controversial  and  slow, 
and  the  tools  limited  and  not  commercially  available. 

4.1.2    Dynamic  Evaluation 


Essentially,  this  approach  "runs  the  program  and  sees  if  it 
works."  Unlike  static  evaluation,  dynamic  evaluation  also  tests  for 
errors  introduced  by  the  compiler,  loader,  operating  system,  libraries 
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and  support  packages,  physical  procedures,  communication  elements,  and 
CPU  hardware.  Static  evaluation  tries  to  exhaust  all  program 
conditions;  dynamic  execution  involves  real  time  and  is  practical  only 
for  selected  test  cases.  Therein  lies  the  basic  "art"  of  testing, 
that  is,  choosing  the  best  test  cases.  Many  schemes  exist.  The 
Department  of  Defense  (DOD)  testing  requires  three  stages:  (1)  unit 
testing  of  discrete  modules;  (2)  subsystem  testing  of  the  integrated 
collection  of  modules;  and  (3)  system  testing  of  the  integrated 
collection  of  subsystems,  actual  hardv;are,  and  real  data.  This  is  a 
reasonable  paradigm  for  other  approaches. 


4.2    Evidence  of  Robustness 


Unlike  correctness,  little  formal  theory  exists  regarding 
robustness  mechanisms.  The  best  that  can  be  achieved  today  is  to  list 
those  methods  that  have  proven  effective  in  existing  systems. 


4.2.1    On-Going  Testing 


Testing  should  not  end  after  system  delivery    and    O&M  commences. 
A  number  of  schemes  have  been  successful. 


Exerci  s[ng :  The  system  is  tested  by  running  simulated 
operations  with  known  responses  that  are  compared  against 
test  results.  This  is  a  well  known  approach  in  testing  DOD 
systems  in  the  field.  A  modified  version  has  seen  recent 
application  in  the  commercial  sector,  where  a  simulated 
minicompany  is  established  in  a  corporation's  financial 
control  system  so  that  the  auditor  can  easily  observe  the 
system's  response  to  test  input  to  the  minicompany.  The 
minicompany  approach  is  also  known  as  the  Integrated  Test 
Facility  (ITF)  method. 


^-  Flaw  Hypothes2s  Method:  In  this  approach,  system  flaws  are 
hypothesized  based  on  analogous  flaws  found  in  other  systems, 
and  are  tested  for  existence  on  the  object  system.  It  is  a 
cost-effective  approach  to  test  case  selection. 
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^-  j^'^P^i^^  ..I^^u- '  Based  on  the  military  Inspector  General 
scheme,  the  test  team  arrives  unannounced  and  runs  tests  on 
the  live  system.  Such  schemes  exercise  the  current  live 
system  and  uncover  possible  unauthorized  versions  or  modified 
operating  procedures. 

^-    ^gasonablenejj  _Checks:    The  system  is  tested    on    its  ability 

to  detect  and    recover    from    typical    human    errors  such  as 

typographical  errors,  out-of-context  actions,  nonsense 
commands  (e.g.,  rewind  card  reader),  etc. 


^'  Ei^y'O'^  Recovery:  The  system  is  tested  on  its  ability  to 
detect  and  recover  from  a  variety  of  hardware, 
communications,  power  interruptions  and  surges,  and  program 
errors.  Of  particular  interest  is  restart,  check  point,  and 
roll-back  options. 


4.2.2    On-Line  Monitoring  and  Control 


One  class  of  service  found  useful  in  DOD  applications  involves 
on-line  control  by  a  System  Security  Officer  (SSO).  The  SSO  is 
concerned  with  misuse  or  subversion  of  the  system.  To  assist  in  the 
detection  of  these  and  other  breaches  of  system  integrity,  the  SSO  has 
control  of  built-in  surveillance,  monitoring,  sutDverter,  and 
journal ing  software.  These  programs  permit  the  SSO  to  test  the 
environment  of  the  system  to  ensure  proper  v;orking  order,  to  log 
current  activity,  and  to  investigate  individual  exception  cases.  The 
concepts  apply  to  systems  integrity  in  general,  beyond  the  DOD 
national  security  concern.  Of  particular  concern  is  the  management  of 
the  system  security  data  base  of  subject  clearances,  object 
classifications,  encryption  keys,  user  identifiers  (IDs),  and 
passwords . 


4.2.3  Redundancy 


A  popular  hardware  approach  to  integrity  has  now  found  limited 
application  in  software.  If  multiple  different  algorithms  exist  for 
computing  a  result,  these  can  be  computed  redundantly  by  different. 
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independent  modules,  as  part  of  the  operational  software,  and  the 
results  can  be  compared  and  exceptions  reported  (possibly  to  the  SSO). 


4.2.4    Support  Control 


Confidence  in  the  system's  robust  behavior  can  be  attributed  to 
the  facility  management  and  O&M  procedures.  These  fall  into  three 
areas : 


£ode  ,.Con tro  1 :  Good  program  libraries  are  required  to  permit 
selective  access  to  system  and  user  code,  and  to  permit 
rational  change  procedures  for  error  correction  and  software 
upgrades. 


^-    Er^ror  ^  Control^:    Errors    will    occur    and    will    need    to  be 
reported,  arrJ^appropri ate  actions  will  need  to  be  taken. 


^-    2.29.4.'!!^'],-?.ti9.'2  Source  program  libraries  are  one  form 

of  d~o c me n t s .  "Us e r  and  system  manuals,  and  other  forms  of 
English  documentation  must  be  kept  current  to  the  level  of 
the  software  in  use  if  errors  are  not  to  be  introduced  by 
dated  descriptions  and  procedures. 


4.3    Evidence  of  Trustworthiness 


Trusted  software  is  obtained  from  a  successful  blend  of  factors: 
(1)  experienced  personnel,  (2)  organized  software  development,  and  (3) 
good  tools.    Each  of  these  factors  may  be  developed    in    a    variety  of 
ways. 


4.3.1  People 


Skilled  people  can  be  as  much  as  twenty  times  more  effective  than 
less  skilled  people  in  the  quality  of  code  they  produce. 
Trustworthiness  of  code  is  improved  by  demonstrating  good  personnel 
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selection  and  training  practices,  and  by  personnel  experience.  The 
DOD  employs  a  system  of  background  investigations  to  screen  personnel 
for  suitability  to  various  levels  of  job  sensitivity. 


4.3.2    Software  Development 


One  trusts  better-made  programs.  Since  a  software  product 
mirrors  its  production  management,  better  production  methods  yield 
better  products.  This  suggests  a  trustworthiness  evaluation  method, 
i.e.,  scrutiny  of  development  practices  yields  insight  into  product 
trustworthiness.  The  following  steps  can  be  taken  to  perform  a 
comprehensive  review  of  the  programming  practices  employed: 


1.    Assess  the  standards,  quality  control  methods,  and  management 
controls  employed.    Are  they  well  documented,  read,  and  used? 


2.    Explore  methods  used  to    make    production    status    visible  to 
management.    Are  the  data  meaningful? 


3.  Determine  the  degree  of  automation  employed  to  enforce  stated 
management  and  programming  practices. 

4.  Use  an  audit  team  to  examine  the  programs  in  depth  for 
compliance  with  stated  management  and  programming  practices. 
Are  they  well  documented? 

5.  Examine  procedures  and  history  of  corrective  action  to 
problems  detected  in  prior  audits,  reviews,  and  tests.  Was 
meaningful  action  taken  to  rectify  problems  and  did 
production  improve? 


4.3.3  Tools 


Good  tools  amplify  skills  and  can  aid  all  aspects  of  trust 
evaluation  by  giving  confidence  in  the  quality,  timeliness,  and 
control  of  program  development.    Among  the  tools  of  significance,  are: 
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1.  Production  Tools:  Language  preprocessors  and  compilers,  test 
case  generators,  program  production  libraries,  proof 
verifiers,  theorem  provers,  assertion  generators. 

2-  l^anagement  Tools:  Configuration  controls,  status  monitors, 
Ttanoards,  quTTity  control  procedures,  error  and  change 
controls,  cost  controls,  module-to-mission  linkage  threads. 


Documentat  i  on  Too  Is :  Flow  charters,  word  processors, 
d 0 cu m en t " 1 i b r ar i es ,  and  change  controls. 


^-  Audit  Tools:  Flaw  lists,  penetrations  analyses,  test  cases, 
flow  charters,  and  redundant  but  independent  production  tools 
to  test  repeatability  (e.g.,  compile  a  randomly  selected 
module  with  the  audit  compiler  and  test  the  object  code 
produced  by  substituting  it  in  the  system). 


5.0    PROGRAM  INTEGRITY  IMPACTS  OTHER  SESSIONS 


Our  broad  interpretation  of  program  integrity  as  a 
multi-dimensional  problem  impacts  the  discussions  of  other  workshop 
sessions.    We  summarize  these  considerations  for  each  session  below. 


5.1    Internal  Audit  Standards 


It    is    imperative    that    internal    audit    standards    reflect  the 

guidance  presented  in  this    session.     Of    particular    concern    is  our 

recommendation  for  agencies  to  perform  self  assessment  (cf.  6.3 
Recommendations) . 


5.2    Qualifications  and  Training 


Since  program  integrity  is  a  complex  technical  subject,  auditors 
need  to  draw  upon  independent,  experienced,  competent,  professional, 
and  technical  computer  science  talent. 
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5.3    Security  Administration 


One  area  often  overlooked  is  the  management  of  system  control 
data,  upon  which  program  integrity  is  dependent.  This  must  fall  to 
security  administration,  possibly  in  the  form  of  a  System  Security 
Officer,  (SSO).  Data  included  in  this  is  described  in  paragraph 
4.2.2,  On-Line  Monitoring  and  Control.  Furthermore,  much  of  our 
discussion  in  Section  4.2,  Evidence  of  Robustness,  is  pertinent  to 
security  administration. 


5.4    Audit  Considerations  In  Various  System  Environments 

We  feel  that  program  integrity  comments  herein  apply  to  all 
software,  regardless  of  application,  including  distributed  systems, 
communications  processors  and  smart  terminals,  controllers,  and 
microcode. 


5.5    Administrative  and  Physical  Controls 


The  whole  facility  management  mechanism  for  controlling  access 
and  changes  to  software  stored  off-line  is  a  cornerstone  of  trusted 
software.  Furthermore,  the  issues  of  the  on-line  System  Security 
Officer  and  remedial  actions  for  backup  and  recovery  impact  physical 
controls.  We  also  point  out  that  system  integrity  can  often  be 
maintained  at  an  acceptable  risk  level  even  with  flawed  programs,  by 
increasing  physical  access  controls  to  reduce  the  exploiter 
population.    This  does  not  preclude  natural  failure  and  human  error. 


5.6    Program  Integrity 


Not  applicable. 


5.7    Data  Integrity 


By  definition,  data  integrity  does  not    impact    program  integrity 
since  system  control  data  is  considered  part  of  program  integrity.  On 


8-15 


the  other  hand,  data  integrity  cannot  exist  vn'thout  program 
integrity.  Where  existing  software  of  dubious  integrity  is  employed, 
caution  is  in  order,  and  steps  should  be  taken  to  reduce  the  risks 
(cf.  6.1  Recommendations). 


5.8  Communications 


See  paragraph  5.4  above 


5.9    Post-Processing  Audit  Tools  and  Techniques 

All  of  Section  4,  Methods    for    Achieving    Program    Integrity,  is 
relevant. 


5.10    Interactive  Audit  Tools  and  Techniques 


All  of  Section  4,  Methods    for    Achieving    Program    Integrity,  is 
relevant. 


6.0  RECOMMENDATIONS 


The  following  consensus  recommendations  are  made  regarding  the 
audit  and  evaluation  of  program  integrity: 


6.1    Existing  Software 


0     Be  cautious  in  assuming    program    integrity,    especially  with 
sensitive  applications. 


0  Although  limited,  tools  and  techniques  for  auditing  and 
evaluating  program  integrity  do  exist.  They  should  be 
applied  via  a  careful  risk  management  analysis. 
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0  Reduce  the  effect  of  the  lack  of  program  integrity  by 
improving  physical,  procedural,  and  management  control,  and 
upgrade  the  O&M  organization. 


0     Reduce  the  exploiter  population  by  access    controls    and  user 
authorization  screening. 


0  Reduce  the  asset  exposure  by  removing  the  asset  from  the 
system  when  it  is  not  in  use.  Encryption  may  be  used  to 
accomplish  the  same  effect. 


Future  Software 


0  Improve  the  production  process  with  rigorous  enforcement  of 
good  programming  practices  throughout  the  program's  full  life 
cycle. 


0  Assure  program  integrity  compliance  at  each  development  stage 
from  mission  objectives,  functional  requirements,  system 
specification,  HOL  code,  and  O&M. 


Organization  Actions 


0  Each  organization  must  do  a  self -assessment  of  its  threats 
and  involvement  in  the  life  cycle  of  the  programs  it  uses. 
The  earlier  the  involvement,  the  better,  depending  on  the 
degree  of  concern  for  security  threats. 


0  Organizations  should  prepare  detailed  guidelines  for 
development  or  acquisition  of  existing  and  future  software, 
with  consideration  given  to  the  auditability  of  program 
integrity. 
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EDITORS'  NOTE 


A  brief  biography  of  the  Session  Chairperson  follows: 

Mr.  Leonard  I.  Krauss  is  a  Manager,  Management  Consulting  Services, 
in  the  New  York  office  of  Ernst  &  Ernst  where  he  is  a  consultant  to 
management  in  the  areas  of  planning  and  control  systems,  data  processing 
management,  and  information  system  security.    His  system  planning  and 
development  experience  includes  a  variety  of  computer  applications  for 
financial  institutions,  manufacturers,  service  companies,  and  other 
organizations.    Mr.  Krauss  was  previously  associated  with  IBM  and 
Union  Carbide.    He  has  also  been  an  officer  and  director  of  several 
companies  and  held  positions  as  Director  of  Management  Systems  and 
Project  Manager  for  Advanced  Management  Systems.    A  registered  profes- 
sional industrial  engineer,  he  has  earned  the  CDP  (Certification  in  Data 
Processing)  and  is  the  author  of  three  popular  books:  Computer-Based 
Management  Information  Systems,  Administering  and  Controlling  the 
Company  Data  Processing  Function,  and  SAFE:    Security  Audit  and  Field 
Evaluation  for  Computer  Facilities  and  Information  Systems.    He  holds  a 
MBA  in  Business  Management  Systems  from  Fairleigh  Dickinson  University 
and  a  BS  in  Industrial  Engineering  from  Pennsylvania  State  University. 
Mr.  Krauss  is  a  frequent  speaker  at  international  management  conferences. 


The  charge  given  to  this  session  was: 

DATA  INTEGRITY:    What  are  the  audit  approaches  and  techniques  for 
evaluation  of  data  integrity  in  an  ADP  environment? 

Data  integrity  is  the  state  that  exists  when  computerized  data  is  the 
same  as  that  in  the  source  documentation  and  has  not  been  exposed  to 
accidental  alteration  or  destruction.    It  includes  both  data  accuracy 
and  data  protection.    Computer  generated  data  involved  in  automatic  de- 
cision making  process  should  also  be  considered. 

Data  integrity  is  an  area  that  has  traditionally  been  addressed  by  the 
audit  community.    This  session  is  to  identify  those  audit  approaches  and 
techniques  that  are  unique  to  an  ADP  environment  and  have  not  been  sub- 
jected to  extensive  coverage  in  the  literature. 


The  consensus  report  that  follows  was  reviewed  by  the  entire  membership 
of  this  group.    It  was  written  by  L.  I.  Krauss  and  S.  W.  Katzke. 
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Data  Integrity  Auditing: 
A  Framework  for  Standards  Development 


1.  INTRODUCTION 


An  audit  and  evaluation  of  ADP  security  calls  for  an  examination  of 
the  system  of  safeguards  used  to  prevent,  deter,  detect,  and  limit  the 
impact  of  undesirable  events. 

An  adequate  system  of  safeguards  is  one  having  design,  implementa- 
tion, and  compliance  characteristics  appropriate  to  the  magnitude  of  the 
risks  and  exposures  assoicated  with  undesirable  events.    Examples  of 
undesirable  events  include:    an  ADP  center  file,  an  unauthorized  update 
to  data  base  records,  and  an  illegal  tap  on  a  data  communications  line. 
Examples  of  exposures  include:    destruction  of  assets,  erroneous  dis- 
bursement of  funds,  embezzlement  and  fraud,  disclosure  of  personal  or 
proprietary  information,  political /military/competitive  disadvantage, 
faulty  decisions,  extra  operating  expense,  legal  and  contractual 
penalties,  interruption  of  critical  ADP  services,  and  loss  of  life. 

In  auditing  and  evaluating  the  system  of  safeguards  for  ADP,  there 
will  be  factors  that  have  either  a  direct  or  an  indirect  bearing  on  data 
integrity.    The  audit  and  evaluation  of  data  integrity  safeguards,  for 
purposes  of  this  report,  is  limited  to  factors  having  a  direct  bearing 
and  which  pertain  to  a  particular  ADP  application  selected  for  examin- 
ation (data  ingegrity  audits  are  conducted  on  an  application-by- 
application  basis). 

Factors  that  have  an  indirect  bearing,  for  purposes  of  this  report, 
include  physical,  operational,  administrative,  and  software  security 
measures  which  are  part  of  the  more  general  system  of  safeguards  and 
which  are  not  usually  peculiar  to  any  one  ADP  application.  These 
general  security  measures  are  recognized  as  being  vitally  important--so 
much  so  that  it  may  be  virtually  impossible  to  have  adequate  data 
integrity  safeguards  for  an  ADP  application  in  an  environment  where 
there  are  significant  inadequacies  in  the  system  of  general  safeguards. 

Inadequacies  in  the  system  of  data  integrity  safeguards  are  some- 
times indicative  of  weaknesses  in  the  general  security  system,  in  much 
the  same  way  that  abnormalities  in  a  person's  blood  pressure  and  cell 
counts  indicate  a  malfunction  in  some  other  part  of  the  body.  The 
auditor  must  be  alert  to  such  possibilities  and  point  them  out,  even 
though  the  scope  of  the  data  integrity  examination  does  not  encompass 
a  detailed  study  of  them. 

Specifically,  a  data  integrity  audit  must  evaluate  the  policies  and 
procedures  that  directly  affect  the  quality  of  all  forms  of  data  (e.g., 
source,  entry,  processed,  and  output)  in  the  application  system  under 
review.    As  a  prerequisite  to  a  data  integrity  audit,  the  auditor 
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must  have  a  clear  understanding  of  the  definition  of  data  integrity  and 
the  objective  and  scope  of  the  audit.    To  perform  the  audit,  the  auditor 
must  first  formulate  an  approach  or  work  plan  and  then  use  appropriate 
and  acceptable  methods  for  conducting  the  audit.    During  the  course  of 
the  audit,  it  is  necessary  that  the  definition  of  data  integrity  and  the 
objective  of  the  audit  always  be  kept  in  mind. 

Section  2  provides  a  definition  of  data  integrity.  Subsequent 
sections  discuss  the  objectives,  scope,  approach  and  methods  f'or  con- 
ducting the  data  integrity  audit. 


2.    DEFINITION  OF  DATA  INTEGRITY 


Data  integrity  is  the  state  that  exists  when  data  are  (within 
defined  limits  of  reliability)  accurate,  consistent,  authorized,  valid, 
complete,  unambiguous,  and  processed  according  to  specifications  in  a 
timely  manner.    It  is  important  that  this  definition  be  constantly 
referred  to  during  the  course  of  a  data  integrity  audit. 


3.    OBJECTIVE  OF  THE  DATA  INTEGRITY  AUDIT 


Keeping  the  definition  of  data  integrity  in  mind,  the  objective  of 
a  data  integrity  audit  of  a  particular  application  system  is  to  render 
an  objective  opinion  based  on  an  evaluation  by  qualified  individual (s) 
as  to  the: 

(1)  Compl iance  with  existing  policies  and  procedures  for 
maintaining  data  integrity 

(2)  Adequacy  of  the  existing  policies  and  procedures 

In  addition,  as  a  result  of  the  compliance  and  adequacy  evaluations, 
corrective  actions  may  be  recommended  to  enhance  the  data  integrity  of 
the  application  system.    Furthermore,  it  is  essential  that  the  date  the 
audit  is  completed  be  recorded  since  it  represents  a  specific  reference 
point.    Any  assumptions  about  the  state  of  the  system's  data  integrity 
made  after  this  date  become  less  and  less  valid  as  time  goes  on. 

When  conducting  the  data  integrity  audit,  it  is  important  that  the 
objective  of  the  audit  be  kept  in  mind. 


4.    SCOPE  OF  THE  DATA  INTEGRITY  AUDIT 


The  scope  of  the  data  integrity  audit  is  necessarily  broad  since 
data  associated  with  an  application  system  exist  in  many  forms  and  are 
affected  by  policies  and  procedures  in  different  parts  of  the  system  and 
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in  the  organization  which  provides  and  uses  the  data.    However,  it  is 
not  generally  practical  to  have  a  data  integrity  audit  include  examin- 
ations of  all  related  system  areas  that  affect  data  integrity.    Among  the 
functions  that  should  be  included  as  part  of  other  audit  procedures  would 
be  verifications  of: 

0    Underlying  physical  facts  represented  by  data  elements 

(e.g.,  counts,  confirmation,  observations) 
0    Software  integrity  and  software  maintenance  controls 
0    Physical,  administrative,  and  operational  security 

To  achieve  the  previously  stated  objective  of  a  data  integrity  audit, 
the  following  areas  should  be  evaluated  with  respect  to  compliance  and 
adequacy  of  existing  policies  and  procedures  and  appropriate  recommenda- 
tions should  be  made  when  they  will  improve  data  integrity. 

Reliability  of  the  Data  Source.    The  sources  of  data  for  an  auto- 
mated application  system  will  vary  according  to  the  application. 
They  may  range  from  data  collected  manually  to  data  collected  by 
automated  data  capture  devices  such  as  automatic  teller  machines 
and  point-of-sale  terminals.    In  some  cases,  source  data  may  be 
transmitted  to  the  application  system  by  feeder  systems. 

Whatever  the  collection  method,  it  must  be  shown  that  the  sources 
are  reliable  ones.    This  requires  the  auditor  to  verify  that  a 
particular  source  of  data  is  the  designated  and  authorized  one, 
that  the  data  obtained  is  current  and  timely,  that  the  data  is 
captured  as  close  to  the  source  as  practical,  and  that  adequate 
separation  of  duties  exists  between  the  creation/collection  and 
the  authorization  of  source  data. 

Source  Data  Preparation.    Once  captured,  raw  source  data  must,  in 
most  cases,  be  prepared  for  entry  into  the  ADP  system.    Data  prep- 
aration requires  the  conversion  of  raw  data,  in  some  instances 
using  a  codification  scheme,  and  transcription  of  the  converted 
data  on  to  additional  source  documents.    Following  conversion  and 
transcription,  the  data  may  be  further  converted  to  a  machine- 
readable  form  (e.g.,  keypunching)  prior  to  entry  into  the  ADP 
system.    In  situations  where  the  source  data  is  collected  in 
automated  form  or  is  keyed  in  directly  to  an  on-line  system,  the 
data  preparation  function  may  be  minimal.    Data  preparation  is 
highly  susceptible  to  human  errors.    Furthermore,  it  is  a  likely 
place  for  the  insertion  and  manipulation  of  records  for  fraudulent 
purposes. 

To  evaluate  source  data  preparation  controls,  it  is  necessary  to 
review  the  data  preparation  policies  as  well  as  the  data  prepara- 
tion procedures  and  training  programs.    The  exi stance  of  appropri- 
ate control  records  for  determining  accuracy,  authorization,  and 
completeness  of  source  data  records  should  be  verified.  Addition- 
ally, data  codification  structures  should  be  reviewed  to  assure 
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consistency  between  data  originating  from  different  sources  or 
source  documents  and  to  assure  accuracy  during  conversion. 

Data  Entry  Control .    Methods  for  entering  data  into  the  ADP  system 
will  vary  widely  from  application  to  application.    In  some  systems 
data  capture  and  entry  take  place  simultaneously  through  devices 
such  as  automatic  teller  machines,  point-of-sale  equipment,  and 
optical  character  readers.    In  others,  keying  of  data  may  take 
place  on-line,  or  in  key-to-tape  and  key-to-disk  devices.    In  some 
cases,  data  may  enter  the  application  system  through  other  systems. 
Like  data  preparation,  data  entry  is  highly  error-prone.    It  is  also 
a  likely  place  for  the  insertion  and  manipulation  of  records  for 
fraudulent  purposes.    Whenever  possible,  detection  and  correction 
procedures  should  be  used  to  prevent  erroneous  data  from  entering 
and  corrupting  the  ADP  system. 

To  evaluate  the  data  entry  control  procedures,  the  auditor  should 
first  review  the  procedures  being  utilized,  including  criteria  for 
accuracy,  completeness,  and  authorization.    Training  programs  and 
plans  should  be  reviewed  as  well  as  instructions  for  data  entry 
that  are  given  to  data  entry  personnel.    It  is  mandatory  to  review 
the  error  detection  and  correction  procedures  and  to  determine  if 
they  are  adhered  to. 

Data  Input  Acceptance  Control.    Input  data  (transactions,  master 
file  and  data  base  maintenance,  tables,  etc.)  can  pass  through 
several  organizational  areas  as  source  data  is  captured,  prepared, 
and  entered  into  the  ADP  system.    In  some  cases,  data  enters  the  ADP 
system  through  feeder  systems  from  distributed  computational  points 
of  the  organization  or  from  outside  sources.    When  the  custody  of 
input  data  changes  hands,  up  to  and  including  the  point  where  it  is 
entered  into  the  application  system,  there  should  be  data  input 
acceptance  control  procedures  which  define  accountability  for  access, 
authentication,  and  accuracy  of  the  input  data. 

As  part  of  a  data  integrity  audit,  it  is  essential  that  input  data 
acceptance  control  procedures  be  evaluated  at  each  control  point 
where  the  input  data  changes  hands.    This  evaluation  should  include 
a  review  of  input  data  acceptance  control  prodecures  for  the  purpose 
of  accountability  and  a  review  of  input  data  access  and  authentica- 
tion controls.    In  addition,  the  existance  of  appropriate  control 
records  for  determining  the  accuracy  and  completeness  of  input  data 
records  should  be  verified. 

Data  Validation  and  Error  Correction.    Prior  to  the  use  of  input 
data  in  an  ADP  system,  the  data  should  be  carefully  validated 
(i.e.,  edited,  checked)  to  detect  erroneous  data.    If  errors  are 
found,  they  should  be  corrected  and  reentered  into  the  system. 
Thus,  when  conducting  a  data  integrity  audit,  it  is  necessary  to 
evaluate  the  data  validation  and  error  correction  procedures.  This 
includes  a  thorough  review  of  existing  procedures--including 
recommendations  for  corrective  action  when  necessary.    In  cases 
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where  manual  procedures  for  data  validation  have  been  replaced  by 
automated  controls,  the  automated  controls  should  be  reviewed  to 
assure  they  perform  the  intended  validation  functions.  Finally, 
controls  for  handling  error  rejects,  corrections  and  data  reentry 
should  be  reviewed. 

Processing  Specifications.    A  key  factor  affecting  the  data  integrity 
of  an  application  system  is  the  assurance  that  data  is  processed  in 
accordance  with  specified  formulas  or  rules.    Ideally,  these  pro- 
cessing specifications  should  be  formalized  and  recorded  with  the 
system  documentation.    Often  these  specifications  are  informal,  not 
recorded  in  any  form  of  documentation,  and  are  known  only  by  a  few 
individuals.    In  some  cases,  the  processing  specifications  may 
exist  in  a  combination  of  states. 

Whatever  the  form  of  the  processing  specifications,  they  must  be 
evaluated  as  part  of  the  data  integrity  audit.    This  evaluation 
should  include  the  review  of  all  processing  specifications  and  the 
review  of  processing  controls  both  within  the  ADP  system  and  between 
the  system  components  that  can  affect  the  processing.    It  would 
cover  controls,  procedures,  and  safeguards  such  as  those  pertaining 
to  processing  of  proper  files,  internally  generated  data,  program 
sequence,  privacy  transformations,  and  access  (user  identification/ 
authentication/authorization).    In  addition,  backup,  recovery,  and 
restart  procedures  should  be  reviewed  as  part  of  an  evaluation  of 
the  processing  specification  of  an  application  system. 

Keep  in  mind  that  a  secure  data  system  operates  without  surprises, 
meaning  that  it  behaves  as  intended  and  according  to  specifications, 
fails  according  to  specifications,  and  gives  a  predictable  response 
when  it  is  functioning  as  expected  as  well  as  when  it  is  failing. 

Output  Controls  and  Distribution  Procedures.    The  accuracy, 
reliability  and  timeliness  of  computerized  output  and  the  access  to 
and  distribution  of  the  output  to  authorized  individuals  are  factors 
affecting  data  integrity.    As  part  of  a  data  integrity  audit,  the 
internal  (i.e.,  automated)  controls  that  ensure  the  quality  of 
output  reports  and  generated  magnetic  media  should  be  evaluated, 
as  should  the  access  and  distribution  procedures  for  the  output. 
In  addition,  output  forms  control  procedures  should  be  reviewed. 

Auditabi lity.    The  ability  to  meet  the  objectives  of  a  data  integrity 
audit  depends,  to  a  large  degree,  on  the  auditabi lity  of  the  appli- 
cation system  under  review.    Auditability  requires  that  procedures 
and  policies  are  in  place  to  assure  that  the  information  and  docu- 
mentation necessary  to  perform  the  data  integrity  audit  is  availa- 
ble, timely  and  adequate,     .hus,  as  part  of  a  data  integrity  audit, 
the  auditability  of  the  ADP  system  should  be  evaluated. 

This  evaluation  stiould  include  a  review  of  the  quality  and  quantity 
of  data  retained  for  auditing,  backup,  and  recovery  purposes,  a 
review  of  the  length  of  time  that  such  is  retained,  and  a  review 
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of  the  currency  and  completeness  of  the  system  documentation.  In 
addition,  an  audit  trail  mechanism  should  exist  and  its  documentation 
should  be  current  and  complete.    In  general,  an  evaluation  of  audit- 
ability  should  include  a  review  of  policies  and  procedures  for 
maintaining  information  that  supports  audit  objectives. 

5.    APPROACH  TO  A  DATA  INTEGRITY  AUDIT 

The  success  of  a  data  integrity  audit  depends  upon  the  thorough  form- 
ulation of  an  approach  or  work  plan  for  auditing  the  application  system. 
During  the  development  of  the  work  plan,  it  is  important  to  keep  in  focus 
the  definition  of  data  integrity,  and  the  objective  and  scope  of  a  data 
integrity  audit.    With  these  in  mind,  the  formulation  of  a  work  plan 
should  include  the  following  steps: 

0    Obtain  an  understanding  of  the  organizations,  policies,  procedures 
and  practices  pertaining  to  the  application  system  under  review. 

0    Obtain  a  general  understanding  of  the  application  system,  includ- 
ing factors  such  as  the  intended  purpose  or  function,  the  require- 
ments of  the  user  community,  the  source  and  flow  of  input  data, 
the  processing  requirements,  the  output  requirements  and  relevant 
time  constraints. 

0    Identify  specific  data  files,  inputs,  processing  steps,  interfaces 
with  other  applications  and  outputs  which  are  utilized  throughout 
the  application. 

0    Identify  specific  control  features  or  points  that  affect  data 
integrity. 

0    Identify  potential  threats  to  data  integrity  for  emphasis  when 
reviewing  the  application. 

0    Decide  upon  the  methodology  (i.e.,  audit  tools  and  methods)  that 
will  be  used  when  conducting  the  audit. 

0    Obtain  an  understanding  of  the  human  factors  that  affect  the  appli- 
cation system,  including  the  human  engineering  aspects  of  the 
user  interface  as  well  as  personnel  areas  such  as  hiring  and 
termination  practices,  employee  moral,  vacation  and  job  rotation. 

0    Obtain  an  understanding  of  the  hardware,  software  and  systems 
technologies  used  in  the  application  system. 

0    Obtain  an  understanding  of  the  training  and  continuing  education 
programs  offered  by  the  organization. 

0    Obtain  an  understanding  of  the  application  system's  development, 
implementation  and  maintenance  controls. 

0    Decide  on  the  form  of  reporting  the  findings,  conclusions,  and 
recommendations  of  the  audit. 
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0    Decide  on  review  procedures  for  the  audit  that  will  assure  high 
technical  quality  of  the  audit. 

0    Decide  on  audit  staffing  and  project  control  methods. 

Once  the  objective,  scope,  approach  and  work  plan  for  a  data 
integrity  audit  of  a  particular  application  system  have  been  established, 
the  audit  should  be  conducted  using  appropriate  audit  tools  and  methods. 
Following  the  audit,  a  draft  report  of  findings,  conclusions,  and 
recommendations  should  be  prepared  by  the  auditors,  reviewed  with 
appropriate  management  personnel,  and  submitted  in  final  form.  If 
corrective  measures  have  been  recommended,  the  managers  ultimately 
responsible  for  data  integrity  should  be  required  to  respond,  in  writing, 
regarding  planned  actions. 


6.    METHODS  FOR  DATA  INTEGRITY  AUDITING 


In  conducting  the  audit,  a  variety  of  audit  tools  and  methods*  may 
be  used  to  determine  the  compliance  with  and  adequacy  of  the  policies 
and  procedures  intended  to  insure  data  integrity  in  the  application 
system  under  review.    Examples  are  discussed  below: 

0    Confirmation  with  users,  customers,  vendors  or  others  familiar 
enough  with  the  data  to  assure  its  accuracy,  completeness,  and 
consistency.    (Except  as  a  spot-checking  technique,  confirmation 
would  be  part  of  other  auditing  procedures.    However,  the  results 
of  a  data  integrity  audit  should  be  carefully  considered  in 
deciding  the  objectives  and  scope  of  auditing  through  confirmation.) 

0    Sampling  techniques  where  portions  of  the  data  population, 
usually  randomly  selected  items,  are  inspected  to  determine 
the  state  of  the  data.    Discovery  sampling  is  intended  to 
uncover  the  existence  of  errors.    If  errors  are  found,  additional 
samples  may  be  taken  and  estimation  sampling  applied  to  them. 
Estimation  sampling  is  used  to  determine  the  extent  of  erronous 
data  in  a  data  base  by  applying  statistical  techniques  to  a 
sample  of  the  data  for  the  purpose  of  predicting  the  amount  of 
contamination.    Attribute  sampling  may  be  used  to  select  records 
based  on  inconsistencies  in  characteristics  within  the  record 
itself  (for  example,  an  accounts  receivable  balance  that  exceeds 
the  credit  limit  by  10  percent  or  more).    It  may  also  be  used  to 
test  a  population  for  the  presence  of  particular  characteristics. 


*Over  25  audit  techniques  are  discussed  in  Audit  Practices  report, 
published  in  1977  by  The  Institute  of  Internal  Auditors  (Altamonte 
Springs,  Florida  32701).    This  was  one  of  the  reports  resulting  from 
the  SAC  (Systems  Auditability  and  Control)  Study. 
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Parallel  processing  checks  for  correct  processing  of  data  by  the 
application  system.    With  this  technique,  data  processed  by  the 
application  system  would  be  processed  by  an  independent  program 
performing  the  same  functions.    The  two  results  would  then  be 
compared. 

Integrated  Test  Facility  (ITF)  allows  the  auditor  to  continuously 
monitor  the  performance  of  the  application  system  by  incorporating 
dummy  master  records  into  the  data  base.    Once  these  records  are 
in  place,  the  auditor  can  process  test  transactions  against  them 
by  including  the  test  transactions  with  the  live  data  during  the 
normal  processing  cycle.    The  auditor  can  then  compare  the 
processing  results  with  predetermined  results. 

System  Control  Audit  Review  Files  (SCARF)  involves  the  placement 
of  auditor-designed  tests  within  the  application  system  program 
code.    During  normal  processing,  the  audit  tests  are  performed 
on  the  processed  data.    Either  processing  exception  or  predeter- 
mined sample  solution  criteria  is  used  to  extract  the  desired 
records  and  write  them  on  a  review  file.    The  auditor  can  then 
examine  the  review  file  and  draw  appropriate  conclusions. 

Tracing  gives  the  auditor  the  ability  to  follow  (trace)  specif- 
ically marked  or  tagged  input  transactions  as  they  are  being 
processed  by  the  application  system.    It  requires  the  insertion 
of  additional  code  into  the  application  system  and  an  extra 
field  in  the  transactions  for  the  tag.    This  code  generates  a 
processing  record  or  trail  for  the  marked  transactions  which 
can  be  analyzed  by  the  auditor  to  determine  if  the  processing 
is  correct. 

Observation  of  personnel  by  visual,  electronic  or  photographic 
means  can  assist  the  auditor  in  determining  compliance  with  and 
adequacy  of  existing  policies  and  procedures  and  in  determining 
erroneous  or  fraudulent  behavior. 

Analysis  by  interrogation  of  existing  data  consists  of  examining 
accounts,  balances  or  other  indicative  and  history  data  to  de- 
termine if  incompatible  relational  conditions  exist  (e.g.,  mis- 
matches between  the  data  and  source  documents  or  other  records). 

Test  decks  or  test  data  can  be  used  for  the  testing  of  new  or 
modified  applications  programs  before  they  are  placed  in  produc- 
tion or  for  testing  the  application  system's  processing  integrity. 
In  either  case,  a  set  of  test  input  transactions  is  processed  by 
the  application  system  and  the  results  are  compared  with  pre- 
determined results. 
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0    Interviews  with  management,  users  and  systems  personnel  on  either 
a  formal  or  informal  basis  can  be  used  to  supplement  system  docu- 
mentation, provide  a  better  understanding  of  existing  policies 
and  procedures,  and  to  verify  compliance  with  these  policies  and 
procedures. 

0    Program  source  code  review,  for  the  purpose  of  a  data  integrity 
audit,  should  be  used  only  as  a  last  resort.    When  information 
about  file  formats,  processing  steps  and  control  descriptions  is 
needed,  it  is  better  to  use  other  documented  sources  such  as 
record  layouts,  system  flow  charts,  program  logic  flow  charts, 
and  program  descriptions.    Analysis  of  program  listings  is  very 
time  consuming  and  generally  requires  skill  in  programming  and 
detailed  knowledge  of  the  specific  programming  language.  In 
cases  where  other  documentation  is  inadequate  or  nonexistent, 
program  listings  usually  provide  the  most  up-to-date  information. 
Consequently,  limited  review  of  source  code  may  be  necessary. 

0    Questionnnai res  are  a  traditional  audit  tool  for  obtaining  infor- 
mation about  an  application  system  and  for  evaluating  controls 
to  determine  adequacy  and  compliance.    They  are  most  effective 
when  tailored  for  particular  types  of  applications  such  as  pay- 
roll, purchasing,  inventory,  etc.  and  provide  preliminary 
information  for  a  more  thorough  evaluation, 

0    Code  analysis  and  mapping  is  accomplished  by  a  software  measure- 
ment tool  that  analyzes  a  program  during  its  execution  to  deter- 
mine how  many  times  each  program  statement  was  executed.  While 
its  original  purpose  was  to  aid  program  development,  mapping 
can  be  used  by  auditors  to  evaluate  program  operation.  However, 
its  use  requires  that  the  auditor  have  a  basic  level  of  under- 
standing of  both  the  application  system's  structure  and  application 
programming. 

0    Automatic  flowcharting  software  consists  of  software  routines 
which  convert  program  source  statements  into  flow  charts  which 
graphically  describe  the  program  logic.    The  use  of  flowcharting 
software  makes  it  easier  to  understand  the  logic  of  a  program 
and  also  guarantees  that  the  auditor  has  a  current  flow  chart 
when  he  is  reviewing  the  application  system.    However,  reading 
the  flow  charts  usually  requires  some  programming  expertise. 
Flow  charts  are  most  useful  when  the  auditor  is  looking  at 
particular  problem  areas.    As  with  source  code  review,  reading 
logic  flowcharts  may  be  of  limited  value  in  auditing  for  data 
integrity. 

0    Procedural  walk-throughs  consist  of  the  auditor  following  the 
flow  of  specific  transactions  through  all  states  of  the  system-- 
from  their  source  until  their  processing  is  completed.  An 
auditor  can  perform  a  walk-through  to  verify  his  understanding 
of  how  the  system  works,  to  check  that  the  system  functions  as 
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the  existing  documentation  describes  and,  in  cases  where  there 
is  inadequate  or  no  documentation,  to  determine  actual  system 
operation.    This  method,  when  used  in  conjunction  with  code 
analysis  and  mapping  and  automatic  flowcharting  software,  can 
provide  the  auditor  with  an  overall  understanding  of  both  the 
manual  and  automated  functions  in  the  system. 

Undercover  observations  give  the  auditor  a  chance  to  view  normal 
system  operations  without  the  system  personnel  being  aware  that 
they  are  being  observed.    This  allows  the  auditor  to  determine 
if  stated  policies  and  procedures  are  being  complied  with  on  a 
day-to-day  basis  and  to  detect  actions  that  might  not  be  per- 
formed if  the  system's  personnel  knew  they  were  being  observed. 
Such  actions  might  include  employee  fraud  or  embezzlement. 

Surprise  visits,  like  undercover  observations,  allow  the  auditor 
to  view  the  system  under  normal  operating  conditions.  Advanced 
notice  of  an  audit  tends  to  increase  anxiety  and  induce  abnormally 
good  behavior  in  personnel. 

Analysis  of  system  activity  logs,  such  as  transaction,  access, 
library,  operator  and  console  logs,  will  aid  the  auditor  in 
evaluating  compliance  with  existing  policies  and  procedures. 
Following  the  analysis  of  the  logs,  the  auditor  may  decide  that 
the  logs  are  not  adequate  for  their  intended  purpose  or,  based 
upon  the  analysis,  that  existing  policies  and  procedures  are  not 
adequate  or  not  being  complied  with. 

Continuous  monitoring  and  surveillance  software.    Software  moni- 
tors are  programs  which  execute  concurrently  with  the  application 
system  in  an  attempt  to  determine  resource  usage  and  system 
bottlenecks.    Surveillance  software  provides  real-time  monitoring 
of  the  application  system  in  an  attempt  to  detect  erroneous  or 
exceptional  events  during  processing.    Specific  examples  of  sur- 
veillance software  are  the  Integrated  Test  Facility  and  the 
System  Control  Audit  Review  Files  discussed  previously. 
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PART  X:  COMMUNICATIONS 


Chairperson:    Jerry  FitzGerald 

Stanford  Research  Institute 

Participants: 


Dennis  K.  Branstad,  Recorder 

National  Bureau  of  Standards 
Lynne  E.  Devnew 

IBM  Corporation 
Milton  Lieberman 

Merrill,  Lynch,  Pierce, 

Fenner,  and  Smith 


Robert  Morris 

American  Telephone  and  Telegraph 
Fred  A.  Stahl 

Columbia  University 
Ken  Sussman 

Bell  Laboratories 


From  left  to  right:  Ken  Sussman,  Lynne  E.  Devnew,  Jerry  FitzGerald, 
Robert  Morris,  Milton  Lieberman,  Fred  A.  Stahl,  Dennis  K.  Branstad. 


Note:    Titles  and  addresses  of  attendees  can  be  found  in  Appendix  A 
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EDITORS'  NOTE 

A  brief  biography  of  the  Session  Chairperson  follows: 


Dr.  Jerry  FitzGerald  was  formerly  a  Senior  Management  Systems  Con- 
sultant at  the  Stanford  Research  Institute  and  is  currently  President 
of  Jerry  FitzGerald  &  Associates.    He  has  also  been  a  state  university 
Associate  Professor  in  business  data  processing  and  EDP  auditing,  a 
systems  engineer  in  a  major  medical  center,  a  senior  systems  analyst 
with  a  computer  manufacturer,  and  an  industrial  engineer  with  a  phar- 
maceutical firm.    His  specialized  professional  competence  lies  in: 
planning/development  of  both  computer-based  and  manually  oriented 
systems  for  financial/industrial  organizations,  hospitals/medical 
centers,  and  educational  institutions.    His  expertise  includes  EDP 
auditing,  EDP  security,  and  data  communications.    His  degrees  are  in 
Industrial  Engineering  (Michigan  State  U. ,  BS)  Business  Administration 
(U.  of  Santa  Clara,  MBA),  and,  from  Claremont  Graduate  School,  an  MA  in 
Economics  and  a  Ph.D.  in  Business.    His  most  recent  publications  include 
Fundamentals  of  Data  Communications,  Wiley/Hamilton  (in  press),  "In- 
House  Staff  Versus  Outside  Consultants",  Proc.  of  the  Academy  of  Man- 
agement, 35th  Ann.  Mtg.,  New  Orleans,  La.,  1975;  "Auditing  EDP  Systems; 
Eight  Areas  of  Control",  Data:    Its  Use,  Organization,  and  Management, 
Proc.  of  Pacific  '75  ACM  Conf . ;  and  a  textbook.  Fundamentals  of  Systems 
Analysis,    John  Wiley  and  Sons,  1973.    He  is  a  member  of  the  Academy  of 
Management. 


The  charge  given  to  this  session  was: 


COMMUNICATIONS:    What  are  the  audit  approaches  and  tech- 
niques for  evaluation  of  communications  in  an  ADP  environ- 
ment?   Include  considerations  of  hardware,  software,  and 
protocols. 

Data  communications  can  be  simply  defined  as  the  interchange  of  data 
messages  from  one  point  to  another  over  communications  channels.  Dedi- 
cated or  dial-up  facilities  can  be  employed  in  a  variety  of  network 
configurations. 

This  session  is  to  analyze  the  various  communication  environments  and 
identify  the  major  aspects  that  the  auditor  must  consider  to  conduct 
an  effective  evaluation.    Audit  approaches  and  techniques  for  such  an 
evaluation  should  be  developed. 


The  consensus  report  that  follows  was  developed  and  reviewed  by  the 
entire  membership  of  this  session. 
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AUDIT  AND  CONTROL  OF 
DATA  COMMUNICATIONS  NETWORKS 
A  Consensus  Report 

Jerry  FitzGerald,  Chairman 
and  (alphabetically  listed) 
Dennis  K.   Branstad,  Lynne  E.  Devnew,  Milton  Lieberman, 
Robert  Morris,  Fred  A.   Stahl,  Ken  Sussman 


1.  INTRODUCTION 


This  paper  presents  guidelines,  rather  than  a  set  of  standards, 
that  can  be  utilized  when  conducting  a  data  communication  security 
audit.     It  is  the  intent  of  the  committee  that  this  paper  form  a  basis 
from  which  EDP  auditors,  either  in  government  or  private  industry,  can 
develop  methodologies  to  audit  their  organizations'  data  communication 
network.     Further  research  in  this  area  might  enlarge  upon  these  guide- 
lines to  develop  a  set  of  standards  that  could  be  utilized  for  auditing 
government  or  private-industry  data  communication  networks. 

Definition  of  the  Special  Data  Communication  Audit 

There  are  many  types  of  audits  that  can  be  performed.     This  paper 
addresses  a  special  type  of  audit  that  involves  only  those  computerized 
systems  that  utilize  a  data  communication  network  and  further  is  limited 
to  the  review  of  the  data  communications  portion  of  these  systems.  A 
special  data  communications  audit  involves  the  end-to-end  network,  and 
all  of  its  associated  hardware,  software,  and  people.     An  audit  of  this 
nature  should  be  conducted  periodically  to  determine  whether  the  infor- 
mation being  transmitted  over  the  network  is  being  properly  safeguarded 
from  its  point  of  origination  to  its  final  destination.     The  frequency 
of  the  audit  should  be  based  on  the  sensitivity  of  the  data  and  appli- 
cations utilizing  the  network.     Additionally,  a  data  coimnunications 
audit  should  be  conducted  whenever  there  is  a  reasonable  doubt  as  to 
the  overall  integrity  of  the  network. 

The  Exposures 

Data  communications  networks  can  be  subjected  to  several  categories 
of  exposure  including  those  to  which  any  other  business  information 
system  might  be  subjected.     For  the  purposes  of  this  audit  the  par- 
ticipants in  this  workshop  identified  the  exposures  to  be  (these  are 
defined  in  Section  3.  of  this  paper): 
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•  Errors  and  omissions 

•  Disaster  and  disruptions 

•  Loss  of  integrity 

•  Disclosure 

•  Defalcation 

•  Theft  of  resources. 


How  to  Audit  a  Data  Communications  Network 

It  is  assumed  that  the  EDP  auditor  conducting  a  data  communications 
audit  has  a  general  understanding  of  how  data  communication  systems  op- 
erate^   i.e.,  how  messages  are  transmitted  over  communication  links. 

It  is  the  opinion  of  the  committee  that  a  data  communication  audit 
should  be  conducted  as  a  transaction  flow  analysis.     Transaction  flow 
analysis  is  a  technique  of  tracing  a  transaction  or  group  of  transac- 
tions from  the  point  of  original  entry  (the  terminal),   through  the  data 
communication  network,   to  the  computer.     Using  this  technique,   the  au- 
ditor is  able  to  evaluate  the  flow  of  transactions,   the  hardware/ soft- 
ware,  the  transmission  media,   and,   in  some  cases,    the  manual  interface 
controls  that  involve  the  people  who  run  the  network.     The  committee  be- 
lieves that  it  is  wise  for  the  auditor  to  trace  the  flow  of  transactions 
starting  at  both  ends  of  the  network  (terminal  and  computer)  and  to  rec- 
oncile the  findings.     The  audit  should  be  conducted  for  the  general  data 
communications  system,   as  well  as  for  each  sensitive  application  using 
the  data  communications  network. 

To  assist  with  the  audit,   this  paper  depicts  a  matrix  that  matches 
the  various  resources  (terminals,   distributed  intelligence,  communica- 
tion lines,   and  the  like)  with  the  previously  mentioned  exposures  (er- 
rors and  omissions,   disaster/disruptions,    loss  of  integrity,   and  the 
like)   so  the  auditor  can  determine  which  resource  may  be  subject  to  what 
type  of  exposure.     The  resources  are  listed  below  and  are  defined  in 
Section  3  of  this  paper  (Figure  1  depicts  the  resources  from  terminals  to 
computer) : 

•  Terminals 

•  Distributed  intelligence 

•  Modems 

•  Local  loop 

•  Lines:     dial-up,   point-to-point,  multipoint,   and  loop 

•  Multiplexor,   concentrator,  switch 

•  Front  end 

•  Computer 
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•  Software 

•  People. 

The  safeguard  matrix  (Table  1)   lists  resources  down  the  left-hand 
vertical  axis^   and  the  exposures  across  the  top  horizontal  axis.  Within 
each  of  the  cells  of  the  matrix,  various  safeguards  are  listed  that  the 
auditor  should  consider  when  reviewing  the  security  of  the  network.  The 
safeguards  are  listed  below  and  are  defined  in  Section  3  of  this  paper: 


/  1  \ 

(1) 

Physical  security  controls 

(  2) 

Audit  trails 

C  j) 

Back-up 

(4) 

Recovery  procedures 

(5) 

Error  detection/correction 

(0) 

Au  then t  ica  t  ion 

C  /) 

Encrypt  ion 

Operational  procedures 

(9) 

Preventive  maintenance 

(10) 

Format  checking 

(11) 

Insurance 

(12) 

Legal  contract 

(13) 

Fault  isolation/diagnostics 

(14) 

Tra  ining/educa  t  ion 

(15) 

Documentat  ion 

(16) 

Testing 

(17) 

Reporting  and  statistics. 

In  conducting  an  audit,   any  resource  that  is  subject  to  an  exposure 
should  have  some  type  of  safeguard  that  the  auditor  must  consider.  In 
doing  this,    the  auditor  would  "walk  through"  the  data  communications 
network  and  evaluate  the  safeguards  listed  for  each  specific  resource 
versus  its  exposure  with  regard  to  the  specific  application  system. 
This  is  an  important  point;   the  auditor  should  use  the  matrix  to  review 
the  communication  security  in  light  of  each  of  the  specific  applications 
that  are  utilizing  the  data  communications  network. 

Limitations 

This  paper  is  intended  to  be  a  basis  for  further  research  that  may 
lead  to  industry /government  standards  for  conducting  data  communication 
audits.     The  matrix  of  resources  versus  exposures  should  be  utilized  to 
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Table  1 

MATRIX  OF  SAFEGUARDS  TO  AUDIT  A  DATA  COMMUNICATIONS  NETWORK 


Resources 

Exposures 

Errors 
&  omis- 
s  ions 

Disas- 
ters & 

disrup- 
t  ions 

Loss  of 
integ- 
r  ity 

Dis- 
closure 

Defal- 
cation 

Theft 
of  re- 
source s 

Terminals 

2,3,5, 
9, 13 

1,3,4, 
8, 11 

1,2,5, 
6,8, 13 

I,  2,6, 

II,  13, 
17 

1,2,6, 

8 

1,2,6, 
17 

Distributed  In- 
tel 1  igence 

2,3,5, 
6,9,10, 
13, 16 

1,3,4, 
8, 11 

1,2,5, 

6,8,13, 

16 

1,11, 
13, 16 

1,2,8 

1 

Modems 

3  5  9 
13 

1,3,8, 
11 

1,13 

1,11, 
13 

1 

1 

Local  loop 

3,5,9, 
13 

1,3,8 

1,5,6, 
7, 13 

1,7,11, 
13 

Lines:  dial-up, 
point-to-point, 
multipoint  &  loop 

3,5,9, 
13 

3,4,8, 
17 

5,6,7, 
13 

1,7,11, 
13 

MUX/CONC/switch 

3,5,9 
13,16 

1,3,8 
11 

1,2,3, 
4,5,6, 
7,8,13, 
16 

1,7,11, 
13 

1,2,6, 
8 

1,2,6 

Front -end 

2,3,4, 
5,9,10, 
13,16, 
17 

1,3,8, 

11 

1,2,3, 
4,5,6, 
8,10, 
13, 16 

1,7,13, 

16 

1,2,6, 
8 

1,2,6 

Computer 

2,3,4, 
5,8,9, 
10,13, 
14,15, 
16, 17 

1,3,4, 
8, 11 

1,2,3, 
4,5,6, 
8,10, 
13, 16 

1,7,13, 
16 

1,2,6, 
8 

1,2,6, 
17 
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Table  1  (Concluded) 


Resources 

Exposures 

Errors 
6c  omis- 
s  ions 

Disas- 
ters & 
disrup- 
t  ions 

Loss  of 
integ- 
rity 

Dis- 
closure 

Defal- 
cation 

Theft 
of  re- 
sources 

Software 

3,4,5, 
8,13, 
15,16, 
17 

I,  3,4, 

II,  15 

1,2.3, 
4,5,6, 
8,10, 
13, 16 

1,7,13, 
16 

6,8, 
12,15, 
16, 17 

1,2,6, 
12, 17 

People 

1,2,3, 
4,6,8, 
10,11, 
13,14, 
15,17 

I,  3,8, 

II,  12, 
15 

1,2,5, 

6,8,11, 

12,14, 

15,16, 

17 

1,2,6, 
8,12, 
13,14, 
17 

1,2,6, 
8,11, 
12,  17 

2,14, 
15,  17 

review  each  application  system  that  is  currently  using  the  data  communi- 
cation network.     The  user  is  advised  that  there  are  some  basic  limita- 
tions that  must  be  recognized.     These  limitations  are  as  follows: 

•  The  safeguards  listed  in  the  matrix  are  intended  only  as 
guidelines,   not  as  standards,   and  should  not  be  considered 
all  inclusive  with  regard  to  a  specific  application  system. 

•  The   safeguards  listed  will  assist  in  making  a  data  commun- 
ications system  secure;   it  must  be  emphasized  that  security 
is  relative,   not  absolute. 

•  Safeguards  listed  may  not  apply  in  all  application  situa- 
tions,  and,    therefore,   a  general  knowledge  of  data  commun- 
ications is  assumed. 

•  The  safeguards  considered  imply  the  state-of-the-art  methods 
in  use  at  the  time  (1977)   this  paper  was  written. 
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2.     USE  OF   THE  AUDIT  MATRIX 


To  conduct  a  data  communications  security  audit  using  the  audit  ma- 
trix, the  auditor  should  first  become  familiar  with  the  committee's  def- 
inition of  resources,   exposures,   and  safeguards. 

The  auditor  should  then,  for  each  resource  utilized  by  each  sensi- 
tive application  on  the  system,   follow  a  four-step  procedure: 

•  Locate  the  resource  on  the  left-hand  vertical  axis. 

•  Read  across  the  row  identifying  each  potential  exposure. 

•  Consider  each  potential  safeguard  for  applicability,  given 
the  specific  application  being  run  on  the  network. 

•  For  each  applicable  safeguard,   evaluate  whether  the  current 
implementation  of  the  safeguard  is  adequate. 

The  matrix  can,  additionally,  be  used  to  audit  a  general  data  com- 
munications system.  The  procedure,  although  basically  unchanged,  would 
be  followed  to  evaluate  system  resources  and  exposures  as  they  apply  to 
the  total  system. 
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3.  DEFINITION  OF  RESOURCES, 
EXPOSURES,  AND  SAFEGUARDS 


Resources 

The  following  10  resources  are  those  resources  that  constitute  an 
end-to-end  data  communications  network  (review  Figure  1) .     This  section 
defines  each  of  the  resources  that  are  listed  on  the  matrix  (Table  1) : 

•  Terminals --The  devices  used  for  input  and/or  output  of  com- 
puter recognizable  information. 

•  Distributed  Intell igence--The  provision  of  capabilities  for 
error  detection  and/or  correction,   authentication,  message 
formatting,   data  validation  and  check  sums,   protocol,  and 
any  other  logical  and  arithmetic  function  for  validating 
the  integrity  of  the  data  transmitted  from  the  terminal. 

•  Modems  -  -Modem  is  an  acronjrm  for  MOdulator/DEModulator . 
The  function  performed  is  conversion  of  the  data  signals 
from  a  terminal  to  electrical  forms  acceptable  for  trans- 
mission on  the  particular  communication  links  employed  and 
vice  versa. 

•  Local  Loop--The  communications  facility  between  the  cus- 
tomer's premises  and  the  communications  carrier  central 
office.     The  local  loop  is  assumed  to  be  metallic  pairs  of 
wire . 

•  Lines--The  common  carrier  facilities  used  as  links  in  the 
communications  network  between  central  offices.     These  in- 
clude terrestrial  and  satellite  facilities. 

-  Dial-Up:  The  switched  telecommunication  network  and  the 
various  services  provided  therein,  e.g..  Toll,  WATS,  CCSA 
(Common  Control  Switching  Arrangements) . 

-  Point-to-Point  Private  Lines:     Dedicated  leased  facili- 
ties between  two  end  points. 

-  Multipoint  or  Loop  Configured  Private  Line:  Dedicated 
leased  facilities  shared  among  several  (greater  than 
two)   end  points. 

•  Multiplexor,   Concentrator,   and  Switch-- 

-  Multiplexor:     A  device  that  combines,   in  one  data  stream, 
several  data  signals  from  independent  end  points. 

-  Concentrator:     An  intelligent  multiplexor. 

-  Switch:     A  device  that  allows  interconnection  between  any 
two  lines  connected  to  the  switch. 
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•  Front-End  Processor--A  device  that  interconnects  the  commun- 
ications lines  to  the  computer  and  performs  a  subset  of  the 
following  functions: 

-  Code  and  speed  conversion 

-  Protocol 

-  Error  detection  and  correction 

-  Format  checking 

-  Authentication 

-  Data  validation 

-  Statistical  data  gathering. 

•  Computer- -An  electronic  data  processing  device  referred  to 
here  only  for  its  communications  processing  capability. 

•  Sof tware--The  instructions  in  the  computer  that  cause  the 
communications  application  processing  functions  to  be  per- 
formed . 

•  People--The  individuals  responsible  for  inputting  data^ 
operating  and  maintaining  the  equipment,  writing  the  soft- 
ware,  and  managing  the  data  communications  environment. 

Exposures 

The  following  six  items  depict  the  basic  areas  of  exposure  that  are 
listed  across  the  top  of  the  matrix.  This  section  defines  the  basic  ex- 
posures to  which  a  data  communication  network  is  subjected: 

•  Errors  and  Omissions--Inadvertent  or  naturally  occurring 
problems  excluding  those  resulting  from  deliberate  or  ma- 
licious actions.     They  include  but  are  not  limited  to: 

-  Inaccurate  data 

-  Incomplete  data 

-  Malfunctioning  devices,   lines,   or  software. 

•  Disasters  and  Disruptions  (natural  and  manmade) --The  de- 
struction or  temporary  breakdown  of  the  personnel  or  fa- 
cilities required  for  the  communication  system  to  func- 
tion.    This  results  from  natural  and  manmade  disasters 
such  as: 

-  Common  carrier  breakdown. 

-  Public  utility  breakdown. 

-  Hardware/software  breakdown. 

-  The  occurrej:ice  of  a  series  of  events  each  with  low 
probability  causing  catastrophic  loss. 


10-11 


•  Loss  of  Integrity--The  condition  that  exists  when  the  sys- 
tem, including  its  hardware,  software,  data,  and  configu- 
ration is  not  in  one  of  its  intended  states,  i.e.,  it  has 
been  subjected  to  accidental,  fraudulent  or  malicious  ac- 
tion or  destruction.  Mere  disclosure  is  not  included  In 
this  definition.  (Errors  and  omissions  were  treated  sep- 
arately in  this  matrix.) 

•  Pis closure --The  unauthorized  exposure  of  information. 

•  Defalcation --The  intentional  breach  of  the  integrity  of  a 
system  or  its  data  by  an  individual  or  a  group  of  indi- 
viduals in  a  position  of  trust  or  performing  their  assigned 
tasks, 

•  Theft  of  Resources--The  use  of  the  facilities  or  services 
of  a  system  for  other  than  the  intended  purposes. 

Safeguards 

The  following  17  safeguards  are  the  major  categories  of  safeguards 
that  an  auditor  should  consider  when  reviewing  the  security  of  a  data 
communication  network.     This  section  defines  each  safeguard.     It  should 
be  noted  that  security  measures  applied  to  data  communication  networks 
can  be  costly.     It  is  of  great  importance  that  a  realistic  and  pragmatic 
evaluation  be  made  of  the  potential  threat  as  well  as  the  possible  safe- 
guards for  countering  the  threat  to  ensure  a  cost  effective  application 
of  these  safeguards.     The  auditor  should  conduct  a  threat  assessment 
with  regard  to  a  potential  loss  of  the  application  involved,   the  proba- 
bility of  that  loss,   and  the  cost  of  providing  an  adequate  safeguard: 

(1)  Physical  Security  Controls--The  use  of  locks,  guards, 
badges,   sensors,   alarms  and  administrative  measures  to 
protect  the  physical  facilities,   computer,   data  com- 
munications,  and  related  equipment.     These  safeguards 
are  required  for  access  monitoring  and  control  for  and 
the  physical  protection  of  the  computer  and  to  protect 
data  communications  equipment  from  damage  by  accident, 
fire,   and  environmental  hazard,   both  intentional  and 
unintentional  in  nature.     These  safeguards  are  employed 
to  detect,   deter,   prevent,   and  report  security  expo- 
sures.    Audit  consists  of  determination  of  existence 

of  specific  physical  security  measures,  effectiveness 
of  their  functioning,   and  testing  of  reliability. 

(2)  Audit  Trails--A  chronological  record  of  system  activi- 
ties that  is  sufficient  to  enable  the  reconstruction, 
review,   and  examination  of  the  sequence  of  environments 
and  activities  surrounding  or  leading  to  each  event. 
Selected  journals  or  reports  include: 

-  Computer  log-on/log-off 

-  Physical  access  log-in/log-out 
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-  Resource  allocation  and  use 

-  Reconciliation  of   inputs   to  outputs 

-  Frequency  of  specific  events 

-  Forward  and  backward  tracing 

-  Network  utilization. 

This  safeguard  is  employed  to  detect,  recover,  correct, 
or  report  security  exposures.  Audit  consists  of  deter- 
mination of  reasonableness,   completeness,   and  scope. 

Back-up--The  availability  and  protection  of  resources 
to  be  used  to  replace  or  duplicate  those  used  in  normal 
operation.     This  includes  operational  and  written  pro- 
cedures for  regular  review,  update,   and  testing  of 
back-up  resources.     This  safeguard  is  employed  to  pre- 
vent loss,   and  to  correct  or  to  help  recover  from  er- 
rors.    Audit  should  determine  appropriateness  of  back- 
up techniques  for  risk  involved. 

Recovery  Procedures--The  actions,   procedures,   or  sys- 
tems used  to  restore  resources  to  normal  operational 
capability  in  a  timely,   cost-effective  manner.  Audit 
should  determine  workability  or  feasibility  of  re- 
covery procedures. 

Error  Detection/Correction--The  techniques,  procedures, 
or  systems  used  to  detect  and  correct  errors  by  meth- 
ods such  as  echoing,   forward  error  correction,   and  au- 
tomatic detection  and  retransmission  methodologies. 
This  may  involve  validation  through  selective  algo- 
rithms,  parity  checks,   check  sum,  etc.     This  safeguard 
is  used  to  detect  and  correct  errors.     The  auditor 
should  determine  limitations  of  techniques,  procedures, 
or  systems. 

Au then t ica t ion --The  act  of  identifying  or  verifying  the 
identity,   authenticity,   and  eligibility  of  a  terminal, 
message,  user,   or  computer.     Authentication  devices  are 
used  to  detect,   prevent,   and  deter  exposures.  These 
include  but  are  not  limited  to: 

-  User  passwords 

-  Keys 

-  Badges 

-  Message  sequencing 

-  Terminal /computer  call  back 

-  Network  protocol 

-  Encryption. 
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The  auditor  should  determine  existence  and  completeness 
of  the  safeguards. 

Encrypt  ion- -Trans  format  ion  of  data  to  hide  its  original 
contents  or  prevent  its  undetected  modification.  The 
considerations  are: 

-  Specified  precisely  to  meet  some  standard^   e.g.,  the 
NBS  Data  Encryption  Standard. 

-  Matched  to  vulnerabilities  and  characteristics  of  the 
communication  system  and  the  data  involved. 

-  Various  ways  to  encrypt,   e-g-^    link-by-link  or  end-to- 
end  . 

-  Requires  administrative  procedures  to  select  keys  to 

be  used,  dictate  when  to  change  them,  and  control  their 
dis  tr  ibut  ion . 

-  Integrate  into  system  design  in  future  applications 
when  justified  by  the  appropriate  cost/risk  analysis. 

-  Add  communications  overhead  to  distribute  keys,  ini- 
tialize and  synchronize  devices,   and  recover  from 
communications  errors. 

Auditor  should  first  evaluate  vulnerabilities  of  system 
and  data,   review  the  objectives  of  the  encryption  sys- 
tem,  and  then  measure  the  effectiveness  of  the  physical 
and  administrative  procedures  supporting  encryption. 

Operational  Procedures--The  administrative  regulations, 
policies^   and  day-to-day  activities  supporting  the  se- 
curity safeguards  of  a  data  communication  system  such 
as  : 

-  Specification  of  the  objectives  of  ADP  security  for 
an  organization,   especially  as  they  relate  to  data 
communications . 

-  Planning  for  contingencies  of  security  "events,"  in- 
cluding recording  of  all  exception  conditions  and 
activities . 

-  Assure  management  that  other  safeguards  are  imple- 
mented, maintained  and  audited,    including  background 
checks,   security  clearances  and  hiring  of  people  with 
adequate  security-oriented  characteristics;  separa- 
tion of  duties;  mandatory  vacations. 

-  Develop  effective  safeguard  for  deterring,  detecting, 
preventing,   and  correcting  undesirable  security 
events • 

-  Cost  effective,   often  resulting  in  related  benefits 
such  as  better  efficiency,   improved  reliability,  and 
economy . 
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Auditor  should  look  for  the  existence  of  current  admini- 
strative regulations,  security  plans,  contingency  plans, 
risk  analysis,  personnel  understanding  of  management  ob- 
jectives, and  then  review  the  adequacy  and  timeliness  of 
the  specified  procedures  in  satisfying  these. 

(9)     Preventive  Maintenance --Scheduled  diagnostic  testing: 
cleaning,   replacement,   and  inspection  of  equipment  to 
evaluate  its  accuracy,   reliability,   and  integrity.  This 
includes : 

-  Develop  schedules  for  testing  and  repair. 

-  Ensure  that  maintenance  personnel  are  given  the  time 
and  resources  to  deter  or  prevent  failures  of  equip- 
ment. 

-  Keep  inventory  of  replacement  parts,  based  on  failure 
statistics,   such  as  Mean  Time  Between  Failure  (MTBF) 
for  each  device. 

-  Keep  maintenance  records  and  analyze  them  for  recur- 
ring problems  or  statistically  unexpected  security 
exposures . 

-  Perform  unscheduled  replacement  or  testing  for  spe- 
cific devices  to  detect  unauthorized  modification 
("bugging,"  etc.).     This  reduces  the  likelihood  of 
failures  during  critical  periods  and,   as  a  by- 
product,  detects  unauthorized  modification  of  re- 
sources . 

Auditor  should  review  maintenance  schedules,  records, 
inventory  of  parts,    "downtime,"  cost-to-repair-or- 
replace  charts,   and  compare  these  with  those  of  sim- 
ilar systems. 

(10)  Format  checking- -A  method  of  verifying  data  as  being 
reasonable  through  checks  and  balances.     Develop  au- 
tomated verification  system  to  detect  data  entry  errors 
using  methods  such  as  range  checking  (numerical  fields), 
record  counts,   alphabetic  characters  in  numeric  fields, 
field  separators,  etc. 

Auditors  should  evaluate  areas  where  format  checking  can 
be  used  and  verify  that  adequate  checks  are  made. 

(11)  Insurance --Financial  protection  against  major  losses. 
Insurance  is  used  to  share  a  potential  or  actual  loss 
and  to  protect  against  or  recover  from  major  disasters 
by  budgeting  resources  over  the  long  term. 

Auditors  should  evaluate  whether  protection  may  be  more 
easily  obtained  from  alternative  safeguards,   and  that 
major  catastrophies  will  not  expose  the  organization  to 
unacceptable  risks. 
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(12)  Legal  Contract--An  agreement  for  performing  a  specific 
service  on  a  specific  costing  basis^   generally  incurring 
specific  liability.     Examples  include  bonding^  conflict 
of  interest  agreements^   clearances^   nondisclosure  agree- 
ments,  and  the  like.     Other  examples  include: 

-  Agreements  establishing  liability  for  specific  security 
events. 

-  Agreements  not  to  perform  certain  acts  or  a  penalty 
will  be  incurred. 

Auditor  should  review  the  legal  document  for  adequacy 
and  protection  afforded. 

(13)  Fault  Isola tion/Diagnostics--The  techniques  used  to  as- 
certain the  integrity  of  the  various  hardware/software 
components  comprising  the   total  data  communications  en- 
tity.    These  techniques  are  used  to  audit  the  total  en- 
vironment and  to  isolate  the  offending  elements  either 
on  a  periodic  basis  or  upon  detection  of  a  failure. 
These  techniques  include: 

-  Diagnostic  software  routines 

-  Electrical  loopback 

-  Test  message  generation 

-  Administrative  and  personnel  procedures. 

Auditor  should  review  the  adequacy  of  the  techniques 
used  for  fault  isolation. 

(14)  Training/Education--Tra  ining  and  education  of  employees 
serves  both  to  aid  in  preventing  problems  and  in  cor- 
recting them  when  they  have  occurred.     It  serves  to 
clearly  define  responsibility  and  to  familiarize  em- 
ployees with  accepted  procedures. 

Auditor^  should    review  ongoing  educational  policies. 

Education  also  includes  training  in  the  whys--including 
why  security  and  controls  are  important  to  the  organi- 
zation.    The  potential  repercussions  of  a  failure  and 
the  need  to  follow  procedures  or  observe  controls  should 
also  be  addressed. 

Auditor    should    ensure  that  management  is  aware  of  the 
need  and  advantages  of  education  and  that  training  is 
used  on  a  continuing  basis. 

(15)  Documenta t ion- -Documentation  is  a  precise  description 
of  programs,   hardware,   system  configuration,   and  pro- 
cedures intended  to  assist  in  prevention  or  problems, 
identifying  the  causes  of  problems,   and  recovering  from 
the  problems.     It  should  be  sufficiently  detailed  to 
assist  in  reconstructing  the  system  from  its  parts. 
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Auditor  should  determine  that  documentation  exists  to 
the  extent  required  to  meet  reasonable  anticipated  needs. 

(16)  Testing --The  techniques  used  to  validate  the  hardware  and 
software  operation  to  ensure  integrity.     Testing^  includ- 
ing that  of  personnel^   should  uncover  departures  from 
specified  operation. 

Auditor  should  determine  that  testing  exists  to  the  extent 
required . 

(17)  Reporting  and  Statistics--The  gathering  and  reporting  of 
information  which  defines  the  usage  of  all  facets  of  the 
data  communications  entity.  The  generation  of  exception 
reports  for  management  including: 

-  Traffic  statistics 

-  Maintenance  statistics 

-  Error  performance 

-  Terminal  usage  by  time  and  activity. 

Auditor  should  determine  that  reporting  and  statistics 
exist  to  the  extent  required  to  meet  future  planning  needs. 
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PART  XI:     POST-PROCESSING  AUDIT  TOOLS  AND  TECHNIQUES 


Chairperson:    Richard  D.  Webb 

Touche  Ross  &  Company 

Participants: 


Leo  Deege 

Defense  Audit  Service 
Philip  M.  McLellan 

Royal  Canadian  Mounted  Police 
Albrecht  J.  Neumann,  Recorder 

National  Bureau  of  Standards 


Michael  J.  Sopko 

GTE  Service  Corporation 
Norman  Statland 

Price  Waterhouse  &  Company 
Robert  Stone 

Uni royal  Corporation 


From  left  to  right:    Richard  D.  Webb,  Philip  M.  McLellan,  Zella  G. 
Ruthberg  (visiting  Vice  Chairman),  Robert  Stone,  Leo  Deege,  Michael  J 
Sopko,  Albrecht  J.  Neumann 


Note:    Titles  and  addresses  of  attendees  can  be  found  in  Appendix  A. 
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EDITORS'  NOTE 


A  breif  biography  of  the  Session  Chairperson  follows: 

Mr.  Richard  D.  Webb  is  a  Manager  in  the  Executive  Office  of  Touche 
Ross  &  Company.    He  is  responsible  for  research  and  development  of  EDP 
audit  policies,  EDP  audit  techniques,  and  EDP  audit  training.    He  had 
significant  responsibilities  on  the  EDP  audit  team  that  investigated  the 
Equity  Funding  situation  for  the  Trustees  in  Bankruptcy.    He  has  design- 
ed and  implemented  audit  software  packages  and  has  been  a  financial  and 
cost  accounting  systems  consultant.    Mr.  Webb  is  a  Certified  Public  Ac- 
countant (IL)  and  a  member  of  the  American  Institute  of  Certified  Public 
Accountants  where  he  is  Chairman  of  the  Audit  Software  Specifications 
Task  Force;  a  member  of  the  Computer  Audit  Subcommittee;  and  a  member  of 
the  Computer  Audit  Techniques  and  Approaches  Audit  Guide  Project  Team. 
He  was  also  a  member  of  the  task  forces  that  drafted  the  AICPA  audit 
guides  entitled,  "Audits  of  Service  Center  Produced  Records"  and  "Audi- 
tor's Study  and  Evaluation  of  Internal  Controls  in  EDP  Systems."    He  is 
a  member  of  the  Board  of  Directors  of  the  New  York  Chapter  of  the  EDP 
Auditor's  Association  and  a  member  of  the  New  York  Society  of  CPAs.  Mr. 
Webb  received  his  BS  in  accounting  from  the  University  of  Minnesota. 


The  charge    given  to  this  session  was: 

POST-PROCESSING  AUDIT  TOOLS  AND  TECHNIQUES:    What  are  the  post- 
processing audit  tools  and  techniques  available  or  needed  for  the 
effective  use  of  the  various  system  journals  and  logs  in  an  audit 
of  computer  security? 

Many  different  logs  and  journals  are  produced,  or  can  be  produced,  that 
provide  important  information  to  the  auditor  evaluating  computer  secu- 
rity.   Two  of  the  major  problems  that  the  auditor  often  encounters  are 
the  overwhelming  volume  of  information  and  inadequate  analytical  tools. 

This  session  is  to  consider  the  type  of  information  needed,  the  most 
effective  and  efficient  method  of  capture,  and  the  tools  and  techniques 
required  for  analysis.    Consideration  should  be  given  to  what  tools  are 
currently  available  as  well  as  those  needed  to  be  developed. 


The  following  is  a  consensus  report  initially  reviewed  by  the  entire 
group. 
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POST  PROCESSING  AUDIT  TOOLS  AND  TECHNIQUES 

by 

A.  J.  Neumann 
N.  Statland 
R.  D.  Webb 


1.  INTRODUCTION 


This  paper  summarizes  t±ie  discussions  and  conclusions  of  the 
session  dealing  with  post  processing  audit  tools  and  techniques.  The 
group  consisted  of  a  mix  of  external  and  internal  auditors,  security 
specialists  and  computer  oriented  general ists.    Early  in  the 
deliberations  it  was  agreed  upon  to  develop  and  adhere  to  an  outline,  to 
discuss  some  basic  definitions,  and  to  agree  on  a  scope  for  a  security 
audit. 

Based  on  a  common  understanding  of  the  scope  of  the  problem,  we 
agreed  to  look  at  available  data  by  dividing  the  total  system  into 
system  access,  input ,  processing  ,  and  output  areas.  We  would  attempt  to 
determine  typical  security  audit  information  requirements;  i.e.  what 
information  would  an  auditor  need  in  the  post-processing  environment  to 
perform  a  security  audit,  and  v*iat  information  might  be  needed  that  is 
usually  not  available  in  today's  environment.    Next  we  would  assess 
existing  tools  and  techniques,  and  identify  needed  techniques. 

The  authors  wish  to  acknowledge  many  contributions  made  during  the 
Miami  meetings  and  constructive  comments  made  during  the  review  of 
several  draft  versions  of  this  paper  by  L.  Deege,  P.  M.  McLellan,  R. 
Stone,  and  M.  J.  Sopko.  H.  Robinson  arranged  the  original  session  but 
was,  however,  unable  to  attend  because  of  a  last  minute  emergency.  He 
did  however  contribute  to  drafts  of  this  paper. 


2.     OBJECTIVES  OF  A  TYPICAL  SECURITY  AUDIT 


The  post  processing  activities  of  the  auditor  are  presented  here  in 
the  context  of  a  security  audit  and  include  confidentiality,  integrity 
and  availability  of  data.    They  also  include  the  degree  of  compliance 
with  approved  procedures.    Our  discussion  was  intended  to  encompass 
environments  ranging  from  those  requiring  very  little  security,  to 
environments  at  the  National  Security  level.    Also,  the  context  of  the 
discussion  does  not  specifically  address  or  exclude  audits  v^ere  the 
objective  is  an  opinion  on:  the  financial  statements;  system  efficacy; 
system  efficiency;  or  v^ether  the  results  of  the  system  are  used 
effectively. 
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General  objectives  of  such  a  security  audit  were  agreed  to  be  the 
determination  of  the  existence,  scope  and  adequacy  of  controls  in  light 
of  the  level  of  information  protection  required  by  the  nature  of  the 
system. 

Several  specific  objectives  were  noted: 

a.  Determine  that  all  transactions  were  completely  processed  and  that 
they  were  processed  once  and  only  once,     (uniqueness  of  transactions). 

b.  Determine  that  each  transaction  is  complete,  accurate  and  authorized, 
(completeness,  accuracy,  and  authorization  controls  for  transactions, 
i.e.  transaction  integrity). 

c.  Determine  that  processing  was  complete,  accurate,  and  authorized, 
(completeness,  accuracy,  and  authorization  controls  of  processing,  i.e. 
processing  integrity) . 

d.  Determine  that  distribution  of  processing  results  was  made  only  to 
authorized  recipients,     (distribution  control) . 

e.  Determine  that  data  and  the  required  use  of  system  resources  were 
recoverable,     (recover ability  control). 

f .  Determine  the  ability  to  detect  and  analyze  security  violations, 
(detection  and  analysis  capability,  i.e.  violation  control). 

It  was  understood  that  the  auditor  would  have  to  first  "understand 
the  system"  being  audited  in  order  to  work  towards  the  stated 
objectives.    Discussion  of  security  audit  led  to  formulation  of  the 
following  definitions. 


3.  DEFINITIONS 


Computer  Security  —  The  protection  of  system  data  and  resources 
from  accidental  and  deliberate  threats  to  confidentiality,  integrity, 
and  availability. 

Computer  Security  Audit  —  An  examination  of  computer  security 
procedures  and  measures  for  the  purpose  of  evaluating  their  adequacy  and 
degree  of  compliance  with  established  policy. 

Note:  This  definition  covers  computer  security,  rather  than  data 
security,  v^ich  is  included  in  the  broader  concept.  It  was  felt  that  the 
definition  of  security  audit  in  FIPS  PUB  39  dealing  with  data  security 
only  should  be  broadened  to  the  definition  given  here. 

Post  Processing  Audit  —  The  post-facto  analysis  of  input,  processing, 
and  output  information  for  the  purpose  of  validating  compliance  with 
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pre-determined  system  requirements  including  those  for  security. 


Log  —  A  chronological  record  of  data  elements  representing  specified 
actions  taken  for  specific  purposes  during  system  operation.  "Data 
element"  is  used  here  in  its  broadest  sense  to  include  application  data 
as  well  as  system  performance  related  data  etc. 

Tools  vs.  Techniques  —  A  technique  is  a  method  of  accomplishing  a 
desired  objective;  thus  a  technique  may  consist  of  procedures  that 
contain  several  tools,  or  a  technique  may  employ  several  tools 
alternately.  For  example  audit  software  is  a  tool  that  can  be  used  in 
many  techniques. 

Transaction  —  A  collection  of  data  about  an  event.    It  may  be  processed 
or  rejected,  but  from  an  auditor's  viewpoint  should  always  be  recorded. 
The  term  is  used  here  in  its  broadest  sense  from  an  operator  action  at  a 
terminal  served  by  a  computer  to  a  financial  transaction  or  a  textual 
message. 


4.     SCOPE  OF  POST  PROCESSING  AUDIT 


While  the  scope  of  a  post  processing  audit  extends  beyond  the  EDP 
system  proper  and  includes  review  of  manual  and  automated  controls,  this 
discussion  deals  only  with  techniques  and  tools  covering  the  EDP  system 
proper.    That  is  the  audit  covers  processing  of  transactions  from  the 
time  of  initial  conversion  of  data  through  intermediate  processing 
stages  and  telecommunications  to  the  delivery  of  output.    The  mode  of 
processing  (that  is,  on-line  vs.  batch)  was  not  considered  to  be  a 
limiting  factor,  though  several  of  the  logs  discussed  may  be  appropriate 
only  in  one  or  the  other  mode.    The  auditor  is  assumed  to  have 
sufficient  knowledge  of  systems  to  be  able  to  judge  the  impact  of  system 
performance  on  security  and  also  to  effectively  review  manual  areas 
prior  to  conversion  and  subsequent  to  output.    Figure  1  shows  in 
diagrammatic  form  the  scope  of  post-processing  security  audit. 


5.     INFORMATION  REQUIREMENTS 


Achievement  of  the  objectives  of  a  security  audit  generally 
requires  information  about  the  following  areas:  ACCESS,  INPUT, 
PROCESSING  and  OUTPUT.    The  auditor  should  review  each  of  the  areas  and 
look  for  information  detail  in  a  log  showing  the  following  five  basic 
types  of  information  labelled  :  WHO,  FUNCTION,  WHAT,  STATUS,  and  TIME. 
(These  are  illustrated  in  tables  1  through  4) . 
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FIGURE  1.  POST  PROCESSING  SECURITY  AUDIT 
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TABLE  1:  SYSTEM  LOG  ACCESS  INFORMATION 


WHO 

FUNCTION 

WHAT 

STATUS 

TIME 

USER  ID 

ENTRY 

SYSTEM  ID 
&  DEVICE  ID 

SUCCESSFUL/ 
UNSUCCESSFUL 

D-T 

USER  ID 

EXIT/ 
RELEASE 

SYSTEM  ID 
&  DEVICE  ID 

<f 

D-T 

D=DATE 
T=TIME 


TABLE  2:  INPUT  LOG  INFORMATION 


WHO 

FUNCTION 

WHAT 

STATUS 

TIME 

TASK  ID 

REQUEST 
TO  OPEN 
FOR  READ 

RESOURCES 
I.E.  FILES, 
DEVICES. 

PROGRAMS 
DATA 

SUCCESSFUL/ 
UNSUCCESSFUL 

D-T 

TASK  ID 

READ 

FILE.  DATA 
ELEMENTS 

rr 

D-T-SN 

USER  ID 

ENTER 

TASK  ID 

B  9 

D-T 

D=DATE  SN=SERIAL  # 
T=TIME 
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TABLE  3:  PROCESSING  LOG  INFORMATION 


WHO 

FUNCTION 

WHAT 

STATUS 

TIME 

TASK  ID 

VALIDATE 

TRANSACTION 
TYPE 
CONTENT 

N/A 

N/A 

TASK  ID 

FORMAT 

LOG 
RECORD 

TRANSACTION 

I  f  A  ■  in/ 

VALID/ 
INVALID 

D-T-SN 
EACH 
TRANSACTION 

T  A  O  1/  in 

lAoK  ID 

COUNT  & 
SUMMARIZE 

N/A 

M  /  A 

N/A 

TASK  ID 

FORMAT 

LOG 
RECORD 

TASK  COUNTS 
&  SUMS 

N/A 

D-T-SN 

TASK  ID 

UPDATE 

MASTER 

N/A 

N/A 

TASK  ID 

SAVE 

MASTER  FILE 
LOG 

NORMAL/ 
ABNORMAL 

D-T-SN 
OF 

TRANSACTION 

TASK  ID 

SAVE 

PERIODIC 
BACKUP  FILE 

N/A 

D-T-SN 

TASK  ID 

COUNT  & 
SUMMARIZE 

DATA  BASE 
LOGICAL  FILE 
FOR  EACH 
TASK 

N/A 

D-T-SN 

D=DATE  SN=SERIAL  # 
T=TIME 
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TABLE  4:  OUTPUT  LOG  INFORMATION 


WHO 

FUNCTION 

WHAT 

STATUS 

TIME 

TASK/ 
USER  ID 

REQUEST 

WRITE 
(UPDATE) 

FILE  ID 
DEVICE  ID 

SUCCESSFUL/ 
UNSUCCESSFUL 
DEVICE/STATUS 
CHANGE 

D-T 

TASK  ID 

WRITE 
(UPDATE) 

DEVICE  ID 
FILE  ID 
MACHINE  OR 
HUMAN 
READABLE 

COMPLETE/ 
INCOMPLETE 

D-T 

D=DATE 
T=TIME 
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WHO  identifies  the  cause  or  initiating  force  of  a  transaction.  The 
cause  may  be  a  person  or  a  process,  manual  tasks,  or  a  program. 

The  FUNCTION  is  descriptive  of  a  processing  action  such  as  "entry", 
"request  to  read",  "validate",  "count"  etc. 

The  items  labelled  WHAT  identify  objects  of  the  processing  action. 
They  may  be  files,  devices,  programs,  or  data  elements. 

The  STATUS  information  refers  to  the  function  and  the  associated 
cause  and  objects.  An  action  may  be  complete  or  incomplete,  correct  or 
incorrect,  etc. 

TIME  provides  a  date-time  stamp  associated  with  the  recorded  action 
and  status.  It  provides  basic  time  information  which  can  be  used  to 
determine  audit  trails,  and  in  general  to  trace  system  continuities.  In 
some  cases  a  transaction  or  record  serial  number  will  be  associated  with 
a  date  time  stamp. 

Tables  1  through  4  show  typical  information  requirements  in  tabular 
form.    These  tables  are  not  all  inclusive  and  should  not  be  considered 
complete  in  any  way.  Ihey  do  illustrate  a  train  of  thought,  and  indicate 
a  methodology  which  could  be  used  to  check  security  information 
requirements  available  in  existing  systems,  and  those  to  be  specified 
for  future  systems.  No  time  sequence  is  to  be  implied  by  the  position  of 
the  rows  in  the  various  tables.  Each  line  in  these  tables  forms  a  basic 
record  of  information  pertaining  to  security,  which  may  be  recorded  or 
logged  and  then  processed  at  a  later  time  for  security  audit  purposes. 


6.     TYPICALLY  AVAILABLE  INFORMATION 


In  most  existing  systems  a  variety  of  information  is  available  for 
post-processing  audits.  A  variety  of  logs  are  prepared  routinely  for 
accounting  purposes,  system  maintenance  and  for  system  performance 
monitoring.    A  console  log  may  routinely  record  and  print  out  coded 
system  malfunctions  in  terms  of  error  messages  and  times  of  occurrence. 
An  event  log  might  also  record  terminal  ID  and  user  ID  of  successful 
system  entries.  It  may  also  record  unsuccessful  entries  and  associated 
passwords  used  on  that  occasion.    Every  user  command,  the  time  of  the 
command,  and  terminal  and  user  ID  may  also  be  logged.    From  an  EDP 
department  accounting  standpoint  there  should  be  records  of  the  program 
or  job  run,  the  various  measures  used  in  billing  (connect  time,  CPU 
time,  resource  units  etc.),  the  user  or  organization  ID,  etc.    Some  of 
this  information  is  useful  for  security  audits. 
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Security  related  information  should  include  time  of  action,  type  of 
action,  record  of  unauthorized  passwords  used,  resource  control,  and 
other  means  used  in  the  violation. 


7.     ILLUSTRATIVE  EXAMPLE:  ELECTRONIC  FUNDS  TRANSFER  SYSTEM 


The  next  paragraphs  illustrate  security  information  requirements  in 
the  context  of  an  electronic  funds  transfer  system.    Figure  2  shows  a 
system  block  diagram,  major  system  components,  and  various  logs  used  for 
security  purposes.    A  number  of  retail  terminals  are  connected  to  a 
regional  communications  controller.  Several  of  these  controllers  may  be 
connected  to  bank  computers  or  to  each  other.    Records  and  logs  are 
maintained  at  the  communication  controllers  and  at  central  bank 
computers. 

The  controller  maintains  a  reference  log  and  a  journal.  Four  major 
software  functions  are  postulated  for  the  central  computer:  the 
operating  system,  and  the  input,  processing  and  output  functions.  All 
of  these  maintain  appropriate  logs  and  records  for  security  purposes. 

7.1    Remote  Terminal  Procedures 

Procedures  at  the  remote  terminal  are  designed  to  build  up  security 
information  in  the  various  logs.  A  customer  is  identified  by  a  personal 
identification  number  to  restrict  access  to  appropriate  file  segements. 
A  transaction  type  may  be  entered,  which  permits  validation  of  the 
terminal  use  for  the  particular  type  of  transaction.    A  further  check 
may  be  made  on  the  terminal  identification,  which  may  be  hard  wired. 
Additional  authorization  codes  may  be  required  to  permit  credit 
operations,  adjustments  i.e.  returns,  and  high  value  debit  transactions. 
Each  acknowledgment  of  a  transaction  is  identified  with  a  sequence 
number,  which  is  generated  in  the  terminal. 


7.2    Message  Security  at  the  Switching  Computer. 

Messages  are  formatted  into  message  headers  and  the  message 
content. 

7.2.1  Message  Headers.  A  header  usually  will  contain  the  following 
information: 

Originating  terminal  ID 
Message  type  designator 
Priority  code 

Message  sequence  number (assigned  at  each  terminal) 
Routing  indicator 
Message  character  count 


11-11 


ZD 
Q. 


3 

o 


111 
y- 

a. 

O 
(J 

z 

CO 


LU 

u 
o 
a: 
o. 


_! 
O 

Q  I- 

II I  I — 


11. 


o 


< 
> 


<  1- 
I-  < 


o 

Q 

a:  UJ 

1-  UJ 

2 

<  H 

u 

5  CO 

OPER 
SYS 

< 

t>o 

<  ^- 

Q. 

O  Q  Di  oo 


u 

< 

< 


fid 

I— 
U 


Dd 
< 


WO 


z 
o 

I— 

< 

fid 

LU 

z 
o 

fid 


< 

_J  z 

<  5 
t-  q; 

UJ  lU 
0£  »- 


<1 


UJ 

a: 
o 

UJ 

u 
o 
q: 

Q. 

o 

UJ 

ID 
O 
UJ 


CS 

LU 
fid 

o 


11-12 


7.2.2  Message  acknowledgment  and  release.  After  validation  of  the 
message  character  count,  the  switching  computer  is  accountable  for  each 
message  until  the  the  receiving  unit  e.g  a  terminal,  host  computer  or 
another  switcning  center  acknowledges  receipt  of  the  message.  If 
message  count,  origin  or  destination  codes  are  invalid,  retransmission 
is  requested,  using  the  same  message  sequence  number. 

7.2.3  Ledger  balancing.  By  maintaining  a  list  of  input  and  output 
actions  for  each  message,  ledgers  are  maintained  in  a  continuous  state 
of  balance. 


7.3  Communications  Processor  Logs 

All  message  header  data  are  maintained  on  the  reference  log,  while 
message  contents  are  stored  on  the  journal  log. 

7.4  Bank  Computer  Functions  and  Logs 

The  input  function  primarily  deals  with  validation  and  editing  of 
the  transactions.  A  transaction  log  is  maintained.    The  operating  system 
maintains  a  system  access  log,  the  processing  function  maintains  a 
master  file  log,  while  the  output  module  maintains  periodic  back  up 
files,  which  may  be  used  during  system  failures  to  reconstitute  records 
and  files.    Table  5  shows  data  required  by  the  system  log.  Sign-on  and 
file  entry  would  require  use  of  encrypted  passwords  with  associated 
indicators  showing  which  files,  devices,  programs  may  be  used.    Table  6 
shows  data  requirements  for  editing  and  validating  of  input 
transactions,  while  tables  7  and  8  show  data  requirements  for  processing 
and  updating,  and  for  output. 


8.     POST  PROCESSING  TECHNIQUES 


Several  post-processing  techniques  were  identified  by  the  working 
group.    They  are  presented  here  by  area  and  without  guidelines  for  use 
in  specific  circumstances  since  use  of  a  specific  technique  would 
require  the  auditor  to  consider  several  factors  such  as  timing  and  cost. 


8.1  ACCESS 

8.1.1  Unsuccessful  accesses.  List  all  unsuccessful  accesses  by  level  of 
security  in  order  to  determine  who  accessed,  and  why  attenpt  was 
unsuccessful.    Determine  frequency  and  quantity.  Determine 
characteristic  patterns  and  compare  to  authorization  table.    This  would 
aid  in  detection  of  unauthorized  users. 
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TABLE  5:  OPERATING  SYSTEM- 
SECURITY  ACCESS  CONTROL  LOG  DATA 


WHO 

FUNCTION 

WHAT 

STATUS 

TIME 

CMRCf  RIRFR 
ouDOoniDtn 

ID 

SIGN-ON 

SYSTEM 

O  1  w  1  L  IVI 

DEVICE  ID 

SlIPPESSFUL/ 
UNSUCCESSFUL 

D-T 

SUBSCRIBER 
ID 

RELEASE 

SYSTEM 
DEVICE  ID 

SUCCESSFUL/ 
UNSUCCESSFUL 

D-T 

SUBSCRIBER 
ID 

ENTER 

TASK  ID 
TRANSACTION 
TYPE 

SUCCESSFUL/ 
UNSUCCESSFUL 

D-T 

TASK  ID 

REQUEST 
TO  USE 
(ACCESS 

FOR  READ) 

RESOURCES 
I.E.  FILES, 
DEVICES. 

PROGRAMS, 
JCL 

PROCEDURES 

SUCCESSFUL/ 
UNSUCCESSFUL 

D-T 

COMPLETION  OF  TASKS  1&3  WILL  REQUIRE  USE  OF  A  STORED,  D=DATE 
ENCIPHERED  PASSWORD  WITH  ASSOCIATED  INDICATORS  OF  T=TIMF 
WHICH  FILES,  DEVICES,  PROGRAMS,  ETC.  THIS  TASK  MAY  USE 


A  "TRAP"  PROGRAM  SHOULD  BE  USED  TO  NOTE  OCCURRENCE  OF  UNUSUAL 
TRAFFIC  PATTERNS. 
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TABLE  6:  SECURITY  REQUIREMENTS  DURING 
EDIT/VALIDATION  OF  INPUT  TRANSACTIONS 


WHO 

FUNCTION 

WHAT 

STATUS 

TIME 

TASK  ID 

VALIDATE 

TRANSACTION 
CONTENT 

N/A 

N/A 

TASK  ID 

FORMAT/ 
WRITE  LOG 
RECORD 

TRANSACTION 

VALID/ 
INVALID 

D-T- 
TRANSACTION 
SN  (INCLUDING 
TERMINAL) 

TASK  ID 

COUNT  &  ADD 
TO  CONTROL 

TOTALS 
MAINTAINED 

FOR  EACH 
TERMINAL  BY 
TRANSACTION 
TYPE 

TRANSACTION 
&  SELECTED 

DATA 
ELEMENTS 

N/A 

N/A 

D=DATE  T=TIME  SN=SERIAL  # 


TABLE  7:  SECURITY  REQUIREMENTS  DURING 
PROCESSING/UPDATE  OF  DATA 


WHO 

FUNCTION 

WHAT 

STATUS 

TBME 

TASK  ID 

UPDATE 

MASTER 
FILES 

N/A 

N/A 

TASK  ID 

SAVE 

MASTER  FILE 
BEFORE/AFTER 
IMAGE  ON  LOG 

NORMAL/ 
ABNORMAL 

D-T- 
TRANSACTION 
SN 

TASK  ID 

COUNT  &  ADD 
TO  CONTROL 
TOTALS 

MASTER  FILE 
RECORDS 
SELECTED  DATA 
ELEMENTS 

N/A 

D-T- 
MASTER  FILE 
VN 

D=DATE    SN=SERIAL  # 
T=TIME    VN=VERSION  # 
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TABLE  8:  SECURITY  REQUIREMENTS  DURING 
OUTPUT  OF  DATA 


WHO 

FUNCTION 

WHAT 

STATUS 

TIME 

TASK  ID 

FORMAT 
SUMMARY 
RECORDS  FOR 
TRANSACTION 
&  MASTER 
FILE  LOGS 

RECORD 
COUNTS  & 
CONTROL 
TOTALS  OF 
SELECTED 

DATA 
ELEMENTS 

N/A 

D-T- 
SN-VN 

TASK/ 
USER  ID 

REQUEST 
WRITE/ 
UPDATE 

FILE  ID 
DEVICE  ID 

SUCCESSFUL/ 
UNSUCCESSFUL 
DEVICE  STATUS 

D— T 

TASK  ID 

WRITE/ 

UPDATE- 

IN-PLACE 

DEVICE  ID 
FILE  ID 
FOR  MACHINE 
OR  VISUAL 
READ 

COMPLETE/ 
INCOMPLETE 

D-T 

TASK  ID 

WRITE 

PERIODIC 
BACKUP  FILE 

N/A 

D-T- 
SN-VN 

D=DATE    SN=SERIAL  # 
T=TIME    VN=VERSION  # 
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8.1.2  Successful  accesses.  List  all  successful  entries  to  determine 
usage  patterns.  Conpare  successful  entries  to  authorization  table. 

8.1.3  Log  continuity  check.  Establish  a  log  continuity  check  to 
determine  when  the  system  did  not  indicate  that  it  was  in  use  and  check 
against  processing  schedule.  All  unscheduled  breaks  in  system  activity 
should  be  explained. 


8.2  INPUT 

Techniques  1,  2,  3  apply  as  shown  in  ACCESS. 


8.3  PROCESSING 

Here  a  variety  of  techniques  can  be  used  to  check  processing 
integrity  and  security  . 

8.3.1  Manual  Checking .  Manual  checking  of  a  selected  set  of  previously 
processed  transactions  can  be  used  to  verify  results  produced  in  an 
actual,  previous  processing  cycle. 

8.3.2  Control  Totals.  Independent  determination  of  the  control  totals  of 
actual  files  by  means  of  audit  programs  permit  checking  of  totals 
against  reported  totals  produced  by  the  system. 

8.3.3  Test  Data.  System  test  data  can  be  used  to  produce  control  totals 
or  results  that    are  to  be  checked  against  predetermined  totals,  (base 
case  /  test  decks  ) 

8.3.4  Integrated  Test  Facility.  Here  the  auditor  selects  special 
transactions  to  be  processed  against  auditor  controlled  file  segments  or 
records.  This  method  is  used  frequently  to  test  selected  processing 
paths  of  on-line  processing  systems.    This  may  be  done  on  a  regular  or 
unscheduled  basis,  and  provides  a  deterrent  to  fraud  since  the  ITF  may 
be  designed  to  be  transparent  to  programming  and  operations  personnel. 
Ihey  would  thus  not  be  aware  of  ongoing  security  audit  testing. 

8.3.5  Tagg ing .  Tagged  transactions (i.e.  transactions  to  which  special 
codes  have  been  assigned  by  the  auditor)  can  be  traced  through  the 
processing  of  live  production  runs,  in  order  to  examine  intermediate 
processing  results. 

8.3.6  Extended  Record  Maintenance.  Extended  record  maintenance  can  be 
used  to  add  and  maintain  transaction  records  within  a  master  file,  that 
can  be  used  to  provide  the  processing  history  of  a  master  file.  In-line 
data  collection  provides  samples  of  data,  or  stratification  as  an 
extension  of  the  application  program. 
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8. 3. 7  Tracing .  Tracing  can  be  used  to  document  use  of  program  modules, 
or  program  instructions  to  process  specific  transactions.    It  is  used  to 
verify  process  logic  and  to  identify  unused  portions  of  computer 
programs. 

8.3.8  Mapping.  Use  of  program  analyzers  permits  mapping  of  all  object 
program  modules  included  in  the  load  image  library  to  determine  what 
special  conditions  lead  to  the  execution  of  each  program  module. 

8.3.9  Reconpilation.  Recompilation  of  the  source  statement  version  of 
the  program,  and  processing  of  the  resultant  object  code  against  a 
recent  set  of  transactions  can  be  done.  A  comparison  of  the  two  sets  of 
results  may  lead  to  evidence  of  inproper  processing.    Additionally  the 
current  source  program  can  be  recompiled  with  the  resulting  object 
module  mechanically  compared  to  the  current  production  module  resident 
in  the  library.    This  technique  would  identify  modifications  to  the 
object  module  not  reflected  in  the  source  code.    Once  the  source  code 
logic  has  been  proven,  an  auditor  controlled  copy  could  be  maintained 
for  subsequent  comparison  with  the  production  version  to  detect  program 
modifications. 

8.3.10  Parallel  simulation.  Parallel  simulation  programs  using  selected 
application  logic,  calculations  and  controls,    relevant  to  specific 
auditing  tests  can  be  used  to  reprocess  selected  actual  transactions. 
Critical  calculations  can  be  verified  by  processing  in  another  language. 
Depending  upon  system  complexity  and  the  degree  of  flexibility 
available,  a  generalized  software  package  could  be  used  to  parallel  the 
operation  of  a  system. 

8.3.11  Retrieval  Programs.  Record  retrieval  programs  can  be  used  to 
select  transactions  that  either  meet  specified  selection  criteria,  or 
are  selected  as  a  result  of  statistical  sampling  criteria.  Printed 
reports  can  be  produced  which  can  be  used  for  further  analysis  and 
investigation. 


8.4  OUTPUT 

The  following  post-processing  techniques  are  used  in  checking 
system  output. 

8.4.1  Output  Listing.  List  the  outputs  and  verify  disposition  of  output, 
including  schedule  compliance. 

8.4.2  Authorization  Listing.  List  authorizations  (as  in  input) . 


The  post-processing  techniques  listed  in  the  previous  paragraphs 
have  been  summarized  and  related  to  the  security  audit  objectives  in 
Figure  3.    It  appears  that  fewer  techniques  are  available  for 
distribution  control,  recover ability  and  violation  control,  than  for 
uniqueness  and  integrity  of  transactions  and  of  processing. 
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9.     NEEDED  TECHNIQUES 


Techniques  could  be  developed  or  inproved  in  two  areas,  those  of 
logging  security  audit  data,  and    analysis  and  manipulation  of  the  logs. 

9.1    Logging  methods 

Security  of  the  security  log  needs  to  be  established.  Security 
data  should  be  considered  for  encryption,  i.e.  passwords  and  critical 
logs  should  be  protected  from  unauthorized  access. 

Security  logs  can  be  established  using  one  or  more  of  the  following 
methods : 

The  sinplest  method  would  be  to  use  the  present  operating  system 
software.  This  would  provide  only  minimal  protection  because  it  is 
dependent  on  the  operating  system  and  the  people  who  control  it. 

A  special  purpose  device,  i.e.  a  tamper  proof,  secure,  recording 
microprocessor ,  actuated  by  special  instructions  contained  in  all 
programs  could  also  be  used.  Such  a  device  would  record  all  activity, 
including  use  of  special  control  programs  (e.  g.  "super-zap"),  that 
normally  leave  no  trace  on  the  systems  log.    Similarly  such  a  device 
could  record  all  calls  to  program  libraries. 

A  complete  hardware  monitor  similar  to  a  cockpit  flight  recorder 
with  probes  at  critical  control  points  throughout  the  system  is  another 
alternative.    It  could  provide  a  complete  security  log,  with  a  proper 
level  of  protection,  independent  of  the  system  being  monitored. 


9.2    Software  Tools 

It  was  the  consensus  of  the  group  that  much  can  be  done  with 
existing  techniques,  and  that  no  new  techniques  needed  to  be  developed. 

Existing  audit  software  could  be  made  easier  to  use,  and  degrees  of 
improvement  could  be  made.  Also  existence  of  software  capabilities  needs 
to  be  publicized, —  many  auditors  do  not  know  "what"  is  available 
"where". 

Available  tools  appear  to  be  too  cumbersome  to  use,  and  often  are 
primitive.    For  example,  certain  procedures  described  earlier,  though 
having  common  objectives,  generally  require  complicated  programming  to 
accomplish  their  goals  using  today's  tools.    Higher  level  software  to 
access  logs  for  audit  purposes  could  be  developed. 

Elements  in  the  various  tools  are  often  not  coordinated,  e.g. 
tracing  and  mapping  .    These  techniques  are  generally  appropriate  to  be 
used  together,  and  facilities  could  be  developed  so  that  they  could  be 
used  together. 
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10.     CONCLUSIONS  AND  RECOMMENDATIONS 


Information  should  be  published  for  the  benefit  of  auditors  on 
"what"  audit  tools  are  available  "where".    That  is,  a  catalog  of  tools 
for  security  audit  should  be  developed.  This  catalog  would  provide 
details  of  components,  and  would  be  indexed  according  to  techniques, 
hardware,  and  software  required  to  use  the  tools.  Comments  about  the 
level  of  difficulty  would  also  be  included. 

Security  log  data  should  be  built  into  new  systems  during  their 
development.    Security  oriented  personnel  should  paticipate  in  planning, 
development  and  design  of  systems,  to  insure  auditability. 

Secure  logging  hardware  components  should  be  explored,  to  provide 
tamper-proof  recording  capability  for  security  audit  purposes. 
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EDITORS'  NOTE 


A  breif  biography  of  the  Session  Chairperson  follows: 

Dr.  Hart  J.  Will  has  been  on  the  Faculty  of  Commerce  and  Business 
Administration  at  the  University  of  British  Columbia  since  1969,  first 
as  Assistant  Professor  and  currently  as  Associate  Professor  of  Account- 
ing and  Management  Information  Systems.    His  teaching  and  research  in- 
terests lie  in:    MIS  analysis,  design,  audit,  control  and  security;  da- 
ta base  management  and  administration;  and  audit  software  in  general 
and  ACL  (Audit  Command  Language)  in  particular.    He  has  worked,  con- 
sulted, taught,  and  published  extensively  in  Europe  and  North  America. 
His  activities  include:    Chairman  of  U.E.C.  International  Symposium 
on  Computer  Auditing:    Legal  and  Technical  Issues,  St.  Augustin,  Ger- 
many: GMD,  June  18-20,  1975  and  Editor  of  Legal  and  Technical  Issues  of 
Computer  Auditing,  the  Conference  Proceedings;  visiting  Research  Pro- 
sessor,  Gesellschaft  fuer  Mathematik  and  Datenverarbeitung  (GMD),  St. 
Augustin,  Germany  1974-75;  founding  chairman  of  an  informal  DBMS  Work- 
shop, 1976-77;  and  currently  Associate  Editor  of  INFOR,  Canadian  Jour- 
nal of  Operational  Research  and  Information  Processing  1977.    His  de- 
grees are;  Diplom-Kaufmann  (Free  University  Berlin),  Ph.D.  (University 
of  Illinois  at  Urbana-Champaign) . 


The  charge  given  to  this  session  was: 

INTERACTIVE  AUDIT  TOOLS  AND  TECHNIQUES:    What  are  the  interactive 
audit  tools  and  techniques  available  or  needed  to  permit  on-line 
auditing  of  computer  security? 

The  Institute  of  Internal  Auditors  considers  internal  audit  a  managerial 
control  which  functions  by  measuring  and  evaluating  the  effectiveness 
of  other  controls.    It  has  become  increasingly  difficult  in  an  ADP  en- 
vironment for  the  auditor  to  fulfill  this  responsibility  in  a  respon- 
sive way  and  continue  to  audit  on  an  after-the-fact  basis.    The  speed 
of  processing  alone  requires  a  different  approach. 

This  session  is  to  explore  the  audit  tools  and  techniques  that  can  be 
applied  today  and  those  that  are  needed  to  be  developed  which  will  per- 
mit on-line  evaluation  of  data  integrity. 


The  consensus  report  that  follows  was  developed  and  reviewed  by  the 
entire  membership  of  this  session. 
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Interactive  Audit  Tools  and  Techniques 
A  Group  Concensus  Report 


Hart  J.  Will  and  group  members 


1  .    EXECUTIVE  SUMMARY 


1.1  Introduction 

1.1.1  Interactiveness 

In  an  audit  context,  interactiveness  is  usually  interpreted  as  on- 
line coding  of  audit  programs,  although  the  interactive  audit  programming 
feature  is  available  only  in  relatively  few  systems.    Another  dimension 
of  interactiveness  is  on-line  audit  processing  in  a  human-machine  dia- 
logue in  terms  of  free-format  audit  investigations  of  a  computerized  in- 
formation system.    In  regard  to  computer  security,  some  use  has  been  made 
of  gathering  on-line  system  performance  information  (SMF,  time-sharing 
session  data,  etc.)  for  purposes  of  near  real-time  monitoring  and  control. 
Yet  in  a  computer  communications  system  which  is  itself  highly  interactive 
and  where  use  of  data  base  technology  is  predominant,  the  requirements 
exist  for  increased  capability  to  use  the  computer  also  as  an  interactive 
audit  tool . 

1.1.2  Research  and  Development 

There  are  many  existing  computer  audit  tools  and  techniques  that  are 
being  used  on  a  partially  interactive  basis.    Interactiveness  is  desir- 
able in  the  development  and  maintenance  of  performance.    The  working 
group  believes  that  research  and  development  is  needed  with  respect  to 
true  interactive  tools  and  techniques.    The  report  includes  some  examples 
of  possible  areas  for  further  study. 

1.1.3  Subject  Areas 

The  following  subjects  are  of  interest  to  the  group: 
-Interactive  use  of  existing  audit  tools  and  techniques  to  increase 
audit  efficiency. 

-Development  of  new  tools  and  techniques  in  order  to  facilitate  the 
performance  assurance  process  in  general  and  auditing  in  particular. 

-Development  and  use  of  techniques  to  increase  the  auditability  of 
computer  systems. 

1 . 2  Summary 

1.2.1    Performance  Assurance 

The  summary  framework  is  that  of  performance  assurance,  which  is 
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defined  as  the  assurance  that  a  computer  system  is  performing  its  intended 
functions  within  a  specified  degree  of  accuracy,  timeliness,  and  data  se- 
curity, and  that  it  is  not  performing  unintended  functions.  Performance 
assurance  is  the  domain  of  several  different  kinds  of  people  and  include 
the  Certified  Public  Accountant,  senior  organizational  management,  inter- 
nal auditors,  the  quality  assurance  function  and  operational  management. 
Basic  definitions  and  objectives  are  covered  in  section  2.    Section  3 
describes  the  performance  assurance  function  in  terms  of  four  activities: 

-Project  control  objectives 

-Information  gathering 

-Analysis  and  evaluation 

-Testing 

1.2.2  Existing  Tools  and  Techniques 

Existing  tools  and  techniques  that  can  be  used  interactively  are 
discussed  in  section  4. 

1.2.3  Needed  Tools  and  Techniques 

Additional  needed  performance  assurance  tools  and  techniques  that 
should  be  quite  useful  in  the  detection  of  malfunctions  of  systems  pro- 
cedures or  control  are  discussed  in  section  5.    It  is  possible  to  identi- 
fy symptoms  relating  to  data  or  program  errors,  anomalous  activity,  ac- 
cess control  breaches  and  any  activity  that  exceeds  pre-determined  thres- 
holds.   The  following  categories  of  tools  measure  these  symptoms: 

-Near  real-time  error  detection  and  correction. 

-Monitoring  of  adequacy  of  controls. 

-Measurement  of  design  accuracy. 

-Program  modification  control. 

-Monitoring  of  system  troubles  or  activity. 

1.3       Use  of  Interactive  Tools  and  Techniques 

The  working  group  has  identified  two  major  categories  of  uses  for 
interactive  computing.    They  are  interactive  audit  programming  and  inter- 
active audit  processing.    These  are  defined  in  section  2  of  the  report. 
In  the  case  of  interactive  audit  programming,  the  benefits  to  the  auditor 
in  developing  his  audit  programs  are  similar  to  the  benefits  in  develop- 
ing and  debugging  any  computer  program.    Interactive  audit  processing 
provides  interactive  access  to  report  data/files  and  interactive  execu- 
tion of  an  audit  program. 

Interactive  access  to  report  data/files  refers  to  the  interrogation 
by  the  auditor  of  report  data/files  which  have  been  stored  by  the  system 
controls  on  files  for  this  purpose.    Examples  would  include  frequency 
counts  of  various  types  of  transactions  on  specific  data  in  attempts  to 
penetrate  security  functions. 

Interactive  execution  of  an  audit  program  refers  to  the  stepwise  ex- 
ecution of  an  audit  program  providing  the  auditor  the  opportunity  to  ex- 
amine intermediate  results  in-line  and  base  the  next  execution  step  in 
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the  program  on  those  intermediate  results. 

The  working  group  has  concluded  that  interactive  techniques  for  au- 
diting has  not  been  wide  spread.    The  reasons  identified  include:  (1) 
Interactive  audit  programs  are  not  widely  available  and  auditors  are  not 
accustomed  to  operating  in  this  mode.    (2)    Interactive  access  to  report 
data/files  requires  that  controls  be  built  into  systems  to  collect  taese 
data  and  to  create  the  report  files.    The  needed  controls  have  not  been 
formalized  sufficiently  to  provide  for  extended  audi tabil i ty.    (3)  In- 
teractive execution  of  an  audit  program  requires  new  software  design  for 
the  auditor  to  use.    Few  such  processors  exist  and  those  that  do  exist 
have  not  received  sufficient  acceptance  and  exposure. 

1.4  Benefits  of  Interactive  Tools  and  Techniques 

A  number  of  benefits  can  be  derived  from  the  use  of  interactive 
tools  and  techniques  to  facilitate  the  performance  assurance  function. 
Since  their  cost  effectiveness  has  not  been  fully  explored,  further  re- 
search and  evaluation  is  warranted. 

Interactive  tools  and  techniques  facilitate  the  focusing  on  system 
or  control  functions  in  as  much  detail  as  is  needed  (Zoom  lense  effect). 
They  allow  the  review  of  events  in  near  real-time,  through  continuous  up- 
dating of  audit  trails  and  recorded  events.    This  provides  the  capability 
to: 

-Screen  for  file  status  conditions. 
-Determine  exception  conditions. 
-Summarize  relevant  data  or  conditions. 
-Display  unusual  conditions. 

They  may  improve  audit  effectiveness  by  providing  additional  capa- 
bilities for  determining  characteristics  and  usage  of  controls. 

They  may  increase  or  improve  the  efficiency  of  audit  by  allowing 
more  immediate  return  on  audit  effort. 

They  improve  timeliness  of  auditing  through  provision  of  immediate 
feedback  and  allow  corrective  action  to  occur  without  delay,  thus  reduc- 
ing exposures. 

They  reduce  clerical  effort  and  audit  preparation  and  allow  the  au- 
ditor to  devote  more  time  to  professional  effort  and  analysis. 

1.5  Further  Deliberation  and  Research 

The  group  feels  that  further  deliberations  and  research  are  required 
in  the  following  areas: 

-Specification  of  design  and  performance  requirements  for  interactive 
audit  tools  and  techniques. 

-Designs  of  interactive  audit  tools  and  techniques  for  interfaces 
with  operating  systems  and  data  base  management  systems. 
-Behavioral  audit  research  to  study  audit  behavior  in  an  interactive 
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human-machine  mode  of  operation. 
-Development  of  a  comprehensive  audit  and  control  theory  to  guide 
Performance  Assurance  (PA)  professionals  in  their  activities  and 
software  designers  in  the  development  of  appropriate  audit  tools 
and  techniques. 


2.    GOAL,  OBJECTIVES,  DEFINITIONS 

2.1  Goal 

The  development  of  an  auditing  approach  for  the  use  of  on-line  or  in- 
teractive techniques  to  achieve  performance  assurance  in  computer  systems. 

2.2  Objectives 

-Define  the  scope  and  requirements  for  interactive  tools  and  tech- 
niques . 

-Review  and  define  auditability  and  control  characteristics  in  com- 
puter systems. 

-Describe  tools  and  techniques  available  and  specify  needed  ones. 
-Develop  criteria  for  the  use  of  these  tools  in  specific  systems 

environments  and  define  the  required  interfaces  (e.g.  with  Data 

Base,  Operating  Systems). 

2.3  Definitions 

2.3.1  Performance  Assurance 

Assurance  that  a  computer  system  is  performing  its  intended  functions 
within  a  specified  degree  of  accuracy,  timeliness,  and  data  security;  and 
that  it  is  not  performing  unintended  functions.    The  level  of  accuracy 
depends  on  the  critical  nature  of  the  applications  and  files  (master 
files,  transactions  and  programs)  as  determined  by  management  criteria. 

2.3.2  Interactive  Tools  and  Techniques 

Tools  and  techniques  that  provide  both  interactive  audit  programming 
and  interactive  audit  processing  support.    As  such  they  facilitate  immed- 
iate access  to  or  uses  of  live  files  (master  files,  transactions  and  pro- 
grams) and  to  performance  assurance  data.    This  includes  interactive  ac- 
cess to  application  and  control  files  as  well  as  continuous  dialogue  be- 
tween human  and  computer  systems.    (See  Figure  1.) 

2.3.3  Interactive  Audit  Programming 

The  development  of  a  computer  audit  program  by  means  of  a  language, 
i.e.  the  auditor  gets  immediate  feedback  from  the  language  on  syntactic 
errors  and  preferably  semantic  errors  as  well  -  such  that  the  audit  pro- 
gram is  instantaneously  debugged  and  ready  for  immediate  (or  deliberate- 
ly delayed)  test  and/or  execution.    Antonyms:    generative  (complier- 
dependent)  programming,  host  language  programming. 
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2.3.4    Interactive  Audit  Processing 


Interactive  Audit  Processing  performs  immediate,  interpretive  execu- 
tion of  computer  audit  program  steps  and  whole  audit  programs  against  on- 
line files  upon  issuance  of  simple,  often  terminal -i ni tiated  commands. 
Antonyms:    Batch  audit  processing.  Off-line  file  processing. 

2.3.5  Interactive  Auditing 

Interactive  auditing  is  dependent  on  interactive  audit  programming 
and  interactive  audit  processing  facilities  as  part  of  a  "self-contained" 
audit  software  system  which  can  be  interfaced  with  client  information 
systems  of  diverse  designs. 
Antonyms:    Batch  auditing. 

2.3.6  On-Line  Auditing 

Refers  to  the  capability  to  audit  in  an  interactive  manner, 

2.3.7  Auditing  of  On-Line  Systems 

Refers  to  the  capability  to  audit  both  the  systems  themselves  and 
their  controls  where  the  dominant  mode  of  processing  is  on-line  (e.g., 
airline  reservation  system,  real-time  process  control,  data  entry  systems, 
etc.) 

2.4       Performance  Assurance  Functions 
2.4.1  Model 

In  order  to  generalize  the  term  "auditing"  the  group  decided  to  il- 
lustrate the  previously  defined  term  "performance  assurance  functions" 
as  shown  in  Figure  2.        /  \ 
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2.4.2  CPA  Functions 

To  review,  evaluate  and  test  an  information  system  and  its  contents 
in  performing  an  objective,  independent  examination  in  order  to  express 
an  opinion  on  financial  statements. 

2.4.3  Internal  Auditor  Functions 

To  ensure  that  data  is  processed  accurately  and  that  assets  are  be- 
ing properly  safeguarded. 

2.4.4  Quality  Assurance  Functions 

To  monitor  and  develop  standards  to  insure  efficient  and  effective 
management  and  utilization  of  computer  resources. 

2.4.5  Operating  and  Line  Management  Functions 

To  provide  continuing  evaluation  of  the  development  and  effective- 
ness of  management  controls  and  degree  of  compliance  therewith.  Controls 
should  be  reviewed  for: 

-Effecti  veness 

-Completeness 

-Consistency. 


3.    PERFORMANCE  ASSURANCE  ACTIVITIES 

3.1  Introduction 

The  purpose  of  the  performance  assurance  (PA)  function,  as  previous- 
ly defined,  is  to  determine  that  a  computer  system  is  performing  its  in- 
tended functions  within  a  specified  degree  of  accuracy,  timeliness,  and 
data  security;  and  that  it  is  not  performing  unintended  functions.  The 
other  part  of  the  definition  mentions    that  the  level  of  accuracy  depends 
on  the  critical  nature  of  the  applications  and  data  as  determined  by  man- 
agement criteria. 

In  illustrating  the  activities  of  the  various  groups  involved  with 
the  performance  assurance  function  we  decided,  for  the  purpose  of  our 
deliberations,  to  identify  the  following: 

-Setting  PA  objectives 

-Gathering  information 

-Performing  PA  analyses  and  evaluations 

-Designing  and  performing  PA  test  procedures. 

These  activities  are  used  in  the  next  two  sections  for  cross-class- 
ification purposes  with  existing  and  needed  PA  tools  and  techniques.  This 
way  it  becomes  possible  to  illustrate  how  the  various  tools  and  techniques 
can  be  used  by  professionals  involved  in  performance  assurance  activities. 
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3.2       Setting  PA  Objectives 


There  are  two  types  of  objectives  to  be  considered  in  performance 
assurance.    The  first  type  of  objective  relates  to  the  nature  and  purpose 
of  the  performance  assurance  testing  (audit  or  testing  objectives) .  The 
second  type  of  objective  refers  to  the  system  to  be  tested.    A  system 
control  objective  or  set  of  objectives  are  established  as  the  basis  or 
the  framework  to  use  in  developing  the  system,  procedures  and  controls 
for  any  system  elements  (applications).    The  system  control  objectives 
describe  what  the  system  is  to  do,  i.e.,  in  effect,  the  goal  to  be  accom- 
plished.   The  objectives  are  developed  from  criteria  set  forth  by  manage- 
ment for  that  particular  area. 

A  development  team,  for  example,  in  designing  a  system,  in  establish- 
ing the  detailed  procedures,  and  in  determining  the  type  and  extent  of 
internal  controls  to  be  built  into  the  system,  can  relate  the  procedures 
and  particularly  the  internal  controls  back  to  the  objectives. 

In  situations  where  system  control  objectives  have  been  defined,  they 
may  be  also  useful  to  the  performance  assurance  group  in  evaluating  the 
controls  used  in  the  specific  system  application.    An  end  result  of  any 
design  and  implementation  of  a  system,  procedures  and  controls  should  in- 
clude a  set  of  documentations  detailing  and  describing  the  user  and  the 
computerized  internal  control  techniques  built  into  that  particular  ap- 
plication.   This  "statement  of  internal  control  techniques"  is  extremely 
important  to  the  performance  assurance  function  and  could  be  a  standard 
for  all  systems. 

3.3  Gathering  Information 

The  information  gathering  phase  of  a  performance  assurance  function 
can  be  described  as  the  obtaining  of  all  the  necessary  information  and 
data  needed  in  order  to  review,  to  evaluate  or  to  establish  systems,  pro- 
cedures, and  controls.    The  material  to  be  gathered  includes,  for  example, 
the  statement  of  internal  control  techniques,  detailed  or  summary  docu- 
mentation, narrative  descriptions  of  the  systems  and  procedures,  flow 
charts,  authorization  listings,  and  similar  data.    If  this  type  of  infor- 
mation and  data  is  not  available,  it  becomes  necessary  for  the  performance 
assurance  group  to  develop  or  prepare  the  material  for  analysis  and  eval- 
uation.   Once  the  group  performing  the  performance  assurance  function  is 
required  to  create  any  or  all  of  the  data  required,  that  group  performs, 
in  effect,  functions  that  the  systems  development  group  should  have  per- 
formed.   The  existence  of  the  material  described  above  is  extremely  im- 
portant to  the  performance  assurance  function  and  could  be  a  standard  for 
all  systems. 

3.4  Performing  PA  Analyses  and  Evaluations 

The  analysis  and  evaluation  process  culminates  in  the  design  and  per- 
formance of  tests  with  respect  to  the  systems,  procedures  and  controls. 
These  tests  may  in  turn,  lead  to  further  analysis  and  evaluation. 
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Two  factors  influence  the  analysis  and  evaluation  activities:  the 
critical  nature  (materiality  and  importance)  as  well  as  the  complexity 
of  the  system  application.    Testing  of  an  application  becomes  more  exten- 
sive and  more  sophisticated  when  an  application  is  critical  and  complex. 
In  these  situations,  it  is  important  for  the  various  groups  involved  in 
performance  assurance  to  be  aware  of  interactive  tools  and  techniques 
that  are  available  for  use  in  on-line  testing  and  in  testing  of  on-line 
systems.    With  knowledge  as  to  when  and  how  they  can  be  used  in  the  test- 
ing process,  audit  programs  can  be  prepared  and  executed  interactively. 
The  available  flexibility  allows  as  to  focus  the  testing  on  important 
control  areas,  on  risk  areas,  and  on  the  proper  balance  between  compliance 
and  substantive  tests.    In  addition,  the  test  programs  can  be  prepared 
to  utilize  non-interactive  tools  and  techniques  where  appropriate. 

3.5       Designing  and  Performing  PA  Test  Procedures 

Based  on  the  analysis  and  evaluation  of  the  system,  its  procedures 
and  controls  it  becomes  necessary  to  design  and  test  the  key  controls 
that  are  being  relied  on.    This  activity  can  be  performed  in  the  follow- 
ing steps: 

-Select  the  verification  technique. 

-Determine  if  computer  assisted  techniques  will  be  used. 
-Prepare  and  perform  the  test  procedures. 

-Review  test  results  and  determine  if  further  tests  are  required. 

3.5.1    Select  the  Verification  Techniques 

In  general,  two  approaches  can  be  applied  in  verifying  controls  and 
processing: 

-Test  of  results:    Select  one  or  more  key  files  or  outputs  of  pro- 
cessing and  confirm  the  results. 

-Test  of  processing:    Perform  specific  tests  of  the  critical 
processes  and  controls  directly. 

3.5.1 .1  Test  of  Results 

Verification  and  testing  of  results  is  usually  performed  by  compar- 
isons of  results  with  independent  files,  organizations  or  physical  items 
or  by  reasonableness  tests.    Examples  of  the  former  would  be  comparison 
of  computer  records  of  personnel  pay  rates  and  inventory  balances  to  in- 
dependent personnel  department  files  and  to  physical  inventory  counts. 
Examples  of  the  latter  would  be  tests  of  values  with  expected  ranges  or 
comparisons  with  similar  information  such  as  budgets  and  results  of  prior 
periods. 

3.5.1.2  Test  of  Processing 

Verification  of  processing  involves  specific  tools  and  techniques 
discussed  in  the  next  two  sections  to  test  specific  manual  and  computer 
controls  and  processing  steps.    For  example,  the  snapshot  technique  re- 
sults in  a  list  of  each  step  of  a  computer  program  as  if  it  is  being  pro- 
cessed and  the  status  of  key  data  elements  as  they  are  being  modified. 
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3.5.2  Determine  if  Computer  Assisted  Techniques  Will  Be  Used 
Use  of  the  computer  will  depend  on: 

-The  nature  of  the  control.    Supervi  si  ng,  for  example,  is  a  control 
primarily  tested  by  observation  or  by  review  of  documented  super- 
visory actions.    Integrity  tests  of  a  data  base  may,  conversely, 
require  the  use  of  a  computer. 

-Availability  of  computer  files  and  processing  time. 

-Cost  justifications. 

-Computer  skills  to  develop  a  computer  program,  if  needed. 

3.5.3  Prepare  and  Perform  Test  Procedures 

The  preparing  and  performing  of  the  test  procedures  are  themselves 
subject  to  controls.    The  controls  must  ensure  that  the  programs  and  pro- 
cedures are  designed  to  achieve  the  desired  test  objectives  and  that  the 
procedures  and  files  are  used  as  specified.    Commonly,  compliance  and 
substantive  tests  are  distinguished  although  they  tend  to  overlap  and  the 
same  test  may  be  applied  both  for  the  systems  and  for  the  data  tests  re- 
spectively. 

Substantive  auditing  relates  primarily  to  the  financial  statements 
as  of  the  end  of  a  fiscal  year.    Substantati ve  tests  are  applied  to  the 
verification  of  dollar  values  and  financial  balances  rather  than  the  ver- 
ification of  internal  control.    Their  extent  is  governed  by  the  reliance 
on  internal  controls  as  determined  by  compliance  tests. 

3.5.4  Review  Test  Results  and  Determine  if  Further  Tests  Are  Required 

This  step  is  an  analysis  and  evaluation  function  to  ensure  that  the 
test  results  are  valid.    It  assumes  that  the  test  methodology,  procedures 
and  results  are  documented  for  subsequent,  independent  review  in  a  final 
evaluation  of  controls  and  related  reliance  and  exposure. 

The  end  result  of  performance  assurance  is  the  determination  whether 
and  to  what  extent  reliance  can  be  placed  on  the  system  and  the  results 
of  system  processing.    While  the  conclusions  reached  by  the  separate 
groups  may  differ  to  some  extent,  they  each  review  the  results  of  the 
testing  to  estimate  system  reliability  in  reaching  their  respective  con- 
cl usions . 


4.    EXISTING  PERFORMANCE  ASSURANCE  TOOLS  AND  TECHNIQUES 

4.1  Introduction 

In  an  attempt  to  review  existing  performance  assurance  (PA)  tools 
and  techniques  in  the  context  of  the  previously  identified  PA  functions, 
traditional  batch  and  interactive  tools  and  techniques  were  identified 
separately.    These  are  summarized  in  Figure  3. 

On  each  of  these,  brief  comments  are  offered  in  terms  of  advantages 
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and  disadvantages,  although  no  attempt  is  made  to  exhaust  the  classifica- 
tion possibilities.    The  major  purpose  of  the  exercise  was  to  identify 
gaps  for  needed  PA  tools  and  techniques  that  are  discussed  in  section  5. 

4.2       Batch  PA  Tools  and  Techniques 

4.2.1  Utility  Programs 

Programs  provided  by  or  acquired  from  hardware  vendors  and  software 
companies  to  facilitate  efficiency,  utilization,  monitoring  and  documen- 
tation.   Because  of  the  vast  number  of  these,  a  short  list  may  suffice 
to  illustrate  the  variety  of  these  systems: 

-SMF  (Systems  Management  Facility) 

-Automated  Flow  Charting  Systems 

-Data  Dictionaries 

-Program  Dictionaries 

-Library  Systems  for  data  and  programs 

-HMBLIST  (utility  to  detect  IBM  0/S  modifications) 

-Comparison  systems  (source  to  object) 

a.  Advantages 

1.  May  be  available  at  no  or  low  cost. 

2.  Provides  additional  facts  for  auditors  and  allows  the  audi- 
tor to  probe  into  computer  systems  beyond  a  data  file  and 
transaction  orientation. 

b.  Disadvantages 

1.  May  require  additional  technical  expertise,  (i.e.  operating 
systems,  DBMS,  etc.) 

2.  Not  tested  and  implemented  as  "audit  tools". 

4.2.2  Test  Decks 

Hypothetical  transactions  and  work  file  records  designed  to  test  the 
controls  and  accuracy  of  program  logic. 

a.  Advantages 

1 .    Provides  a  highly  specific  test  of  individual  control  fea- 
tures and  exception  conditions. 

b.  Disadvantages 

1.  Difficult  to  develop  and  maintain  test  data  due  to  program 
modification. 

2.  Requires  special  computer  runs  unless  a  test  module  is  avail- 
able. 

3.  Seldom  comprehensive  enough  to  provide  an  adequate  test  of 
reports  and  statistics.    An  audit  standard  should  be  that 
test  data  is  never  posted  to  live  files. 

4.2.3  Audit  Modules 

Special  audit  subroutines  are  sometimes  contained  in  application  pro- 
grams to  perform  specific  audit  functions  such  as  an  aging  of  accounts 
or  to  eliminate  the  impact  of  test  data  on  the  printed  reports  (see  ITF 
on  the  following  page). 

a.  Advantages 
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1 .  Provides  for  the  execution  of  special  audit  tasks  if  required. 

2.  Can  be  "triggered"  at  any  time, 
b.  Disadvantages 

1.  Require  expert  programming  and,  depending  on  the  design, 
special  operating  procedures. 

2.  May  be  invoked  by  non-authorized  personnel. 

4.2.4  ITF  (Integrated  Testing  Facility) 

Means  of  passing  test  transactions  through  a  computer  system  simul- 
taneously with  live  transactions  without  adversely  affecting  live  files 
or  outputs.    A  separate  set  of  outputs,  including  statistics  and  reports, 
are  produced  for  a  minicompany.    This  not  only  ensures  that  the  test  ma- 
terial does  not  interfere  with  any  outputs  concerning  the  real  company, 
but  also  enables  the  auditor  to  check  that  statistics  and  reports  are 
being  prepared  correctly. 

a.  Advantages 

1.  Testing  in  a  live  environment  routinely. 

2.  No  special  running  time  required. 

3.  No  effect  on  live  records. 

4.  Provides  reports  and  statistics. 

b.  Disadvantages 

1.  Difficult  to  produce  and  maintain  a  complete  set  of  test 
data . 

2.  Requires  special  programming  to  integrate  the  test  subsystem 
with  the  live  system. 

4.2.5  Test  Data  Generator 

A  computer  method  to  generate  hypothetical  transactions  for  testing 
purposes . 

a.  Advantages 

1 .    Automated  development  of  test  transactions  and  work  file 
records . 

b.  Disadvantages 
(See  Test  Decks) 

4.2.6  Snapshot 

Technique  of  capturing  the  status  of  data  at  a  particular  point  in 
time  of  the  producing  cycle,  e.g.,  triggered  by  specific  transaction  types, 
that  are  identified  by  "tags"  (tagging). 

a.  Advantages 

1.  A  good  method  for  a  very  specific  purpose. 

2.  May  reduce  "logging"  requirements. 

b.  Disadvantages 

1.  Requires  frequent  monitoring  by  auditor  to  avoid  "over-tag- 
ging" . 

2.  May  be  too  limited  for  general  audit  applications  and  may 
affect  proper  "logging"  procedures  negatively. 

4.2.7  Tracing 
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A  technique  to  identify  the  sequence  of  actual  exceptions  of  pro- 
gram code,  triggered  by  specific  transaction  types  -  identified  by  "tags" 
-  on  conditions  (as  under  Snapshot) 

a.  Advantages 

(as  under  Snapshot) 

b.  Disadvantages 

(as  under  Snapshot) 

4.2.8  SCARF  (System  Control  Audit  Review  File) 

Incorporation  of  auditor  -  determined  reasonableness  tests  into  nor- 
mal data  processing  applications  for  the  purpose  of  tagging  and/or  ex- 
tracting exceptional  data  into  audit  files. 

a.  Advantages 

1.    Continuous  exception  reporting  (see  Audit  Modules) 

b.  Disadvantages 

1 .    Processing  time 

4.2.9  Audit  Software  Packages 

High-level,  data  processing  languages  to  provide  data  access  and 
computational  manipulations  in  addition  to  specific  audit  functions  such 
as  aging,  confirmations,  sampling,  etc.    The  functions  performed  by  the 
various  software  packages  are  not  all  equivalent  in  terms  of: 

-capabilities,  i.e.,  computation,  sampling,  compares,  etc. 

-interfacing  with  data  (i.e.,  DBMS  and  file  structures); 

-efficiency  of  execution  (i.e.,  running  time,  auditor  preparation, 
etc . ) 

a.  Advantages 

1.  Provides  independent  data  gathering  and  analysis  of  data 
files . 

2.  Improves  efficiency  of  auditor  time  and  can  assist  in  ex- 
panding the  scope  of  audits. 

3.  Provides  access  to  the  entire  universe  of  data. 

b.  Disadvantages 

1 .    Processing  time  can  be  longer  than  use  of  standard  program- 
ming languages. 

A  standard  should  be  that  all  audit  software  packages  should  be  restricted 
to  a  read-only  mode. 

4.2.10  Parallel  Simulation 

It  is  a  means  of  testing  computer  application  processing  by  using 
the  same  input  data  and  files  as  the  application  systems  and  attempting 
to  produce  the  same  results.    The  simulation  results  are  compared  to 
"live"  results  confirming  the  results  of  computer  applications  processing 
or  identifying  areas  of  descrepancies  for  further  analysis. 

a.  Advantages 

1.  Compliance  testing  of  application  programs  can  be  performed 
with  live  data  without  jeopardizing  files. 

2.  Application  program  functions  tested  can  be  analyzed  pri- 
marily through  non-technical  user  documentation  (error  and 


12-15 


balancing  procedures), 
b.  Disadvantages 

1.  Requires  good  knowledge  of  functions  performed. 

2.  Time  required  to  develop  simulation  program. 

4.3       Interactive  PA  Tools  and  Techniques 

The  group  identified  two  interactive  audit  tools  available  to  date 
and  suggests  that  these  be  further  studied  and  evaluated.    We  also 
followed  two  additional  leads  to  what  were  supposedly  other  existing 
interactive  audit  tools,  but  these  proved  to  be  unsuccessful. 

4.3.1  ACL  (Audit  Command  Language) 

ACL  is  available  in  two  versions  at  the  University  of  B.C.  in  Van- 
couver, B.C.    The  first  is  running  under  the  Michigan  Terminal  System 
(MTS  Operating  System)  and  is  used  extensively  in  teaching  (both  academic 
and  professional  through  CICA)  and  research.    The  IBM  version  runs  under 
the  IBM/OS/VSl  system  and  is  used  by  internal  and  external  auditors  as 
well  as  consultants.    As  the  first  fully  interactive  audit  language,  ACL 
represents  a  pioneering  effort  to  combine  the  various  performance  assur- 
ance functions  into  a  single  professional  user  language. 

4.3.2  NAARS  (National  Automated  Accounting  Research  System) 

NAARS  has  been  developed  jointly  by  the  AICPA  and  Mead  Data  Central, 
Inc.    It  is  possible  to  search  interactively  (through  a  computer  terminal) 
the  full  text  of  the  financial  statements,  footnotes  and  auditor  reports 
from  the  published  annual  reports  to  shareholders  of  over  3,500  companies. 
Other  files  accessible  are  various  AICPA  publications  as  well  as  federal 
securities  law  and  federal  trade  regulations. 


5.    NEEDED  PERFORMANCE  ASSURANCE  TOOLS  AND  TECHNIQUES 
5.1  Introduction 


The  mentioned  performance  assurance  (PA)  tools  and  techniques  that 
are  in  existence  to  date  are,  in  many  cases,  quite  useful  in  an  auditing 
situation.    However,  these  tools  are  in  many  instances  little  utilized 
by  both  auditors  and  quality  assurance  personnel.    Their  potential  may 
be  unknown,  or  their  applicability  to  performance  assurance  may  not  be 
obvious.    In  some  instances  the  tools  are  designed  for  another  purpose 
(e.g.  hardware  or  software  monitors)  and  their  applicability  to  security 
or  performance  assurance  is  not  intuitively  obvious. 


The  following  subsection  describes  and  explains  categories  of  needed 
tools  and  specifies  requirements  for  their  design  and  development. 
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5.2       Needed  Tools  and  Techniques 


The  tools  and  techniques  described  below  can  be  utilized  in  two  ma- 
jor areas.    Detection  of  malfunctions  or  inadequacies  of  systems,  proce- 
dures, or  controls  can  be  accomplished  interactively  through  monitoring, 
trace  or  test  facilities.    It  is  also  possible  to  measure  the  "health" 
of  a  system  looking  for  symptoms  such  as  excessive  errors,  anomalous  ac- 
cess to  a  sensitive  file  or  excessive  changes  to  a  given  program.  This 
is  analogous  to  the  tests,  probes  and  data  gathering  performed  by  the 
medical  profession  to  diagnose  disease  and  requires  analogous  judgments 
by  PA  professional s . 

5.2.1  Near  Real-Time  Error  Detection  and  Correction 

The  tools  in  this  category  are  useful  in  detecting  and  when  practi- 
cal, correcting  errors  in  computer  systems  as  they  occur  before  any"dam- 
age"  has  occurred.    Examples  of  damage  include  the  incorrect  automatic 
disbursement  of  large  amounts  of  funds  in  a  funds  disbursing  system  or 
false  feedback  in  a  process  control  system.    These  controls  are  oriented 
to  the  operational  system  "in  the  whole".    It  is  assumed  that  the  hardware 
and  individual  system  modules  have  already  been  tested  and  verified,  but 
that  failures  may  occur  when  the  various  subsystems  are  operating  together 
as  a  larger  system.    We  submit  that  the  following  tools  are  needed: 

-Interface  Data  Monitoring  and  Testing  -  routines  that  exist  to  test 
data  at  each  interface  between  modules  in  a  system  in  terms  of  range, 
limits,  and  validity  of  fields. 
-Threshold  Detection  -  hardware  and  software  monitors  to  measure  var- 
iant and  invariant  characteristics  of  systems  to  detect  and  immedi- 
ately abort  in  cases  of  unusual  usage  patterns. 

5.2.2  Monitoring  of  Adequacy  of  Controls 

The  tools  in  this  category  provide  for  the  on-line  testing  of  the 
predetermined  and  specified  controls  that  have  been  built  into  the  sys- 
tem.   They  permit  the  auditor  to  perform  tests  on  the  operational  system 
to  detect  potential  trouble  spots.    We  submit  that  the  following  tools 
are  needed: 

-Software  Behavior  Monitoring  -  these  routines  would  exist  in  a  dor- 
mant state  in  a  system  and  when  invoked  by  an  auditor  would  begin 
monitoring  the  behavior  of  specified  software  modules  in  terms  of 
accesses,  inputs,  outputs,  and  frequency  of  usage. 

-Configuration  Auditing  -  through  access  to  this  routine,  the  audi- 
tor can  instantly  get  information  on  the  current  configuration  of 
the  operational  system  for  particular  use  in  large  teleprocessing 
systems . 

-Interactive  Tracing  -  routines  similar  to  generalized  debug  packages 
can  allow  an  auditor  to  step  through  the  operational  cycle  of  a  sys- 
tem, monitoring  both  changing  data  values  and  synchronization  of 
events,  and  making  modifications  to  data  values  to  verify  the  ade- 
quacy of  controls  at  the  module  interfaces. 

-Artificial  Load  Generators  -  routines  to  permit  the  auditor  to  gen- 
erate controlled  amounts  of  transactions  and  input  data  to  test  the 
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system  under  varying  conditions  of  loading. 

5.2.3  Measurement  of  Design  Accuracy 

In  this  section  we  address  tools  and  techniques  for  specifying  and 
documenting  systems  and  controls.    It  is  possible  to  verify  system  speci- 
fications against  functional  requirements  for  systems  as  well  as  system 
controls. 

We  submit  that  the  following  tools  are  needed: 

-Requirements  Specification  Languages  -  computer  languages  for  spe- 
cifying system  requirements  to  permit  verification  against  function- 
al requirements. 

-Control  Feature  Specifications  -  formal  methods  for  programmers  to 
document  control  features  such  that  auditors  can  "easily"  understand 
their  applications,  function,  and  anticipated  performance. 

5.2.4  Program  Modification  Control 

The  tools  in  this  category  would  permit  the  auditor  to  verify  the 
adequacy  of  the  procedures  for  controlling  program  modifications  through 
on-1 ine  testing. 

We  recommend  the  following  tools: 

-Program  Modification  Detection  -  check  sums  and  similar  routines 
can  be  used  to  detect  modification  of  systems,  applications  and 
control  software. 

-Program  (Modification)  Audit  Trails  -  through  interrogating  a  par- 
ticular on-line  file  the  auditor  could  get  complete  information  on 
every  program.    In  addition,  it  should  be  possible  to  recognize 
changes  to  a  particular  program,  including  who  made  each  change, 
when  it  was  made,  the  problem  that  caused  the  change,  and  when  the 
modified  program  became  operational. 

5.2.5  Monitoring  System  Trouble  Indicators 

The  tools  in  this  category  would  permit  an  auditor  to  interrogate 
files  containing  information  on  the  execution  of  and  system  control  of 
various  security  features.    The  recommended  needed  tools  are: 

-Utilization  Frequency  Monitoring  -  provides  frequency  information, 
on-line,  concerning  accesses  to  any  privil edged  module,  device, 
data,  and  transaction. 

-Utilization  of  Control  and  Security  Features  -  interrogation  of  this 
file  would  allow  an  auditor  to  obtain  information  on  the  utiliza- 
tion of  any  security,  control,  error  detection,  or  error  correction 
feature  in  the  system  including  frequency  of  usage  and  results  of 
execution;  an  example  would  be  information  on  data  before  and  after 
execution  of  an  automatic  error  detection  feature. 
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Figure  3 


Figure  4  summarizes  the  tools  and  techniques  we  feel  are  needed  to 
fulfill  the  various  performance  assurance  functions.  A  separate  column 
"control"  was  added  to  indicate  that  some  of  these  tools  and  techniques 
may  also  be  used  (already)  for  internal  control  purposes.  Auditors 
should  be  aware  of  them  to  recognize  their  potential  benefit  in  the  in- 
formation gathering  function  in  particular. 
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6.    SUMMARY  AND  RECOMMENDED  FOLLOWUP 

6.1  Introduction 

This  final  section  provides  both  a  brief  and  general  summary  of  the 
recognized  need  for  interactive  audit  tools  and  techniques  and  offers  a 
few  recommendations  for  appropriate  followup  on  the  subject. 

6.2  Need  for  Interactive  Tools  and  Techniques 

In  spite  of  the  apparent  lack  of  awareness  of  interactive  tools  and 
techniques  for  performance  assurance  functions,  the  group  recognizes  the 
need  for  such  tools  and  tries  to  summarize  their  benefits  in  the  execu- 
tive summary  (see  section  1.4). 

The  existing  tools  listed  in  section  4.3  deserve  the  attention  of 
all  professionals  working  in  the  performance  assurance  field  and  should 
be  discussed  and  studied  in  greater  depth  and  detail. 

In  identifying  needed  tools  and  techniques  (see  section  5)  the  group 
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tries  to  broaden  the  outlook  of  all  PA  professionals  and  hopes  to  stimu- 
late further  discussion  both  on  the  auditability  of  modern  information 
systems  and  on  the  ways  for  performing  comprehensive  PA  audits. 

6.3       Recommended  Followup 

The  group  feels  that  further  deliberation  and  research  is  required. 
We  would  like  to  pursue  the  following  topics  as  early  as  possible  and  ask 
for  support  to  discuss  them: 

-Design  criteria  for  interactive  PA  tools  and  techniques. 

-Interface  designs  of  interactive  PA  tools  and  techniques  with  oper- 
ating systems  (OS)  and  data  base  management  systems  (DBMS). 

-Behavioral  audit  research  to  study  interactive  human-machine  behav- 
ior in  the  context  of  performance  assurance. 

-Development  of  a  comprehensive  audit  and  control  theory  to  guide 
PA  professionals  in  their  work  and  software  designers  in  the  devel- 
opment of  PA  tools  and  techniques. 

6.3.1  Design  Criteria 

Since  a  few  interactive  PA  tools  and  techniques  exist,  it  is  possible 
to  consider  them  as  prototypes  which  deserve  further  study  and  evaluation 
by  the  large  number  of  professionals  active  in  the  performance  assurance 
field.    It  may  be  possible  to  adopt  some  of  the  existing  tools  or  become 
feasible  to  specify  design  and  performance  requirements  for  future  sys- 
tems . 

6.3.2  Interfaces 

All  interactive  PA  tools  and  techniques  require  an  interface  with  the 
operating  system  and  many  of  them  will  require  an  interface  with  the  sys- 
tem performing  data  base  management  functions.    Yet,  hardly  any  PA  pro- 
fessional is  involved  in  the  design  and  standardization  of  OS  and  DBMS. 
Differences  in  OS  and  DBMS  or  inherent  weaknesses  of  any  one  of  these 
may  make  the  interfacing  of  PA  and  audit  functions  inefficient  or 
ineffective.    The  group  therefore  urges  all  professionals  to  recognize 
the  need  for  feasible  interface  designs  and  urges  them  to  get  involved 
in  deliberations  concerning  these  important  interfaces. 

6.3.3  Behavioral  Research 

Behavioral  research  is  needed  to  determine  which  audit  software 
functions  are  valuable  as  interactive  features.    Since  audit  requirements 
vary  with  projects  and  with  time,  some  interactive  tools  may  be  relevant 
only  in  certain  instances.    Furthermore,  under  certain  conditions  the 
audit  tool  used  may  have  an  effect  on  the  procedure  and  also  on  the  con- 
clusions reached  by  the  auditors.    It  is  therefore  necessary  to  recog- 
nize that  the  audit  approach  may  be  dependent  on  the  tool  used,  and  vice 
versa.    PA  functions  may  become  much  easier  or  much  more  difficult,  un- 
less the  interplay  between  auditors  and  their  tools  is  recognized  and 
studied  in  considerably  more  depth  than  was  so  far  possible. 
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6.3.4  Theory 


It  has  become  feasible  to  develop  a  comprehensive  audit  and  control 
theory  for  the  performance  assurance  functions,  because  it  is  now  possi- 
ble to  monitor  interactive  human-machine  behavior  in  the  PA  context. 
Consequently,  it  will  be  possible  to  guide  PA  professionals  in  their 
tasks  and  to  develop  "intelligent"  PA  tools  and  techniques,  thus  making 
the  performance  of  the  various  PA  functions  covered  in  this  report  more 
and  more  convenient  and  effective. 
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133. 
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APPENDIX  A:    WORKSHOP  ATTENDEE  LIST 


This  appendix  lists  the  Workshop  attendees  alphabetically.  The 
general  format  of  a  listing  is  as  follows  with  the  square  brackets  in- 
dicating the  location  of  the  various  pieces  of  information. 


Line  1 : 

Line  2: 
Line  3: 
Line  4,5, 


Name 


Workshop  Role 
in  addition  to 
being  an  attendee 


/Part  of  ProceedingsN 
Vcontributed  to  / 


[Job  Title  and/or  Office  Title,  if  known] 

[Name  of  Organization] 

[Address] 


Robert  P.  Abbott  (IX) 
Presi  dent 

EDP  Audit  Controls 

7700  Edgewater  Drive,    Suite  325 

Oakland,  California  94621 

Donald  L.  Adams,  Keynoter  (II) 
Managing  Director, 

Administrative  Services 
American  Institute  of  Certified 

Public  Accountants 
1211  Avenue  of  the  Americas 
New  York,  New  York  10036 

N.  D.  Babic  (IX) 
Manager  of  Information 

Service  Planning 
Atlantic  Richfield  Company 
515  South  Flower  Street 
Los  Angeles,  California  90071 

Sid  Baurmash  (IV) 
Partner 

Seidman  &  Seidman 
1200  18th  Street,  N.W. 
Washington,  D.C.  20036 


Robert  P.  Blanc  (XII) 
Staff  Assistant 

Institute  for  Computer  Sciences 

and  Technology 
National  Bureau  of  Standards 
Washington,  D.C.  20234 

Sheila  Brand,  Recorder  (VI) 
Bureau  of  Supplemental  Security 

Income  Privacy  Coordinator 
Social  Security  Administration 
6401  Security  Boulevard 
2-D-3  Oak  Meadows  Building 
Baltimore,  Maryland  21235 

Dennis  K.  Branstad,  Recorder  (X) 
Chairman,  FIPS  TG-15 
Systems  Architecture  Section 
Systems  &  Software  Division,  ICST 
National  Bureau  of  Standards 
Washington,  D.C.  20234 

Peter  S.  Browne,  Recorder  (XII) 
President 

Computer  Resource  Controls 
6  Stevens  Court 
Rockville,  Maryland  20850 
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Henk  Brussel  (XII) 
Faculty  of  Commerce 
University  of  British  Columbia 
Vancouver,  British  Columbia 
Canada       V6T  1W5 

Edmund  L.  Burke  (VIII) 
The  MITRE  Corporation 
P.  0.  Box  208 

Bedford,  Massachusetts  01730 

Richard  Canning,  (VIII) 
President 

Canning  Publications 

925  Anza  Avenue 

Vista,  California  92083 

Dwight  Catherwood  (IX) 

Supervisor 

Ernst  &  Ernst 

515  South  Flower  Street,  Suite  2700 
Los  Angeles,  California  90071 

Adolph  Cecula  (IV) 
U.  S.  Geological  Survey 
National  Center,  Stop  804 
12201  Sunrise  Valley  Drive 
Reston,  Virginia  22092 

P.  J.  Corum  (VI) 
Assistant  Chief  Inspector 
Bank  of  Montreal,  Inspection 

Department 
129  St.  James  Street  West 
Montreal ,  Quebec  H2Y  1L6 
Canada 

David  L.  Costello  (V) 

Deputy  Chief  Auditor-EDP 

Bank  of  America  (8-900) 

315  Montgomery  Street 

San  Francisco,  California  94137 

Linwood  M.  Culpepper  (V) 
Mathematician 

David  W.  Taylor  Naval  Ship 

Research  &  Development  Center 
Bethesda,  Maryland  20084 


Howard  R.  Davia  (III) 
Director  of  the  Office  of  Audit 
General  Services  Administration 
19th  &  F  Streets,  N.W. 
Washington,  D.C.  20405 

Leo  Deege  (XI) 
Defense  Audit  Service 
Room  624,  Lynn  Building 
nil  North  19th  Street 
Arlington,  Virginia  22209 

Ike  Dent  (VI) 

Director  of  Security  &  Quality 
Control 

Credit  Bureau  Inc.  of  Georgia 
P.  0.  Box  4091 
Atlanta,  Georgia  30302 

Lynne  E.  Devnew  (X) 
Financial  Controls  Systems 

Program  Manager 
IBM  Corporation 
Data  Processing  Division 
1133  Westchester  Avenue 
White  Plains,  New  York  10604 

Donald  L.  Eirich  (V) 
Associate  Director,  Logistics 

&  Communications  Division 
U.  S.  General  Accounting  Office 
441  G  Street,  N.  W. ,  Rm.  5814 
Washington,  D.  C.  20548 

Jerry  FitzGerald,  Chairman  (X) 
Management  Systems  Consultant 
Information  Systems  Management 

Department 
Stanford  Research  Institute 
Menlo  Park,  California  94025 
and  currently  with: 
Jerry  FitzGerald  &  Associates 
Management  Consulting 
506  Barkentine  Lane 
Redwood  City,  California  94065 
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Thomas  Fitzgerald  (V) 
EDP  Auditor 

Manufacturers  Hanover  Trust 

4  New  York  Plaza 

New  York,  New  York  10015 

C.  W.  Getz  (IV) 

Regional  Commissioner 

Automated  Data  &  Telecommunications 

Services 
General  Services  Administration 
525  Market  Street 
San  Francisco,  California  94105 

Malcolm  Blake  Greenlee,  Chairman  (V) 
Assistant  Vice  President 
Comptroller  Division,  WOS 
F-31,  T-20 
Citibank 

20  Exchange  Place 

New  York,  New  York  10005 

Peter  D.  Gross  (VI) 
Computer  Sciences  Corporation 
6565  Arlington  Boulevard 
Falls  Church,  Virginia  22046 

Thomas  L.  Hamilton  (VI) 
Corporate  Systems  Development  & 
Servi  ces 

Administrative  Services  Division 
Eastman  Kodak  Company 
Rochester,  New  York  14650 

Carl  Hammer,  Chairman  (VI) 
Director,  Computer  Sciences 
Sperry  UNI  VAC  Computer  Systems 
2121  Wisconsin  Avenue,  N.W. 
Washington,  D.C.  20007 

Robert  V.  Jacobson,  Coordinator 

Assistant  Vice  President 

Chemical  Bank 

55  Water  Street 

New  York,  New  York  10041 

S.  Jeffery,  Host  (I, III) 

Chief,  Systems  &  Software  Division 

Institute  for  Computer  Sciences 

and  Technology 
National  Bureau  of  Standards 
Washington,  D.C.  20234 


Stuart  W.  Katzke,  Recorder  (IX) 
Systems  Architecture  Section 
Systems  &  Software  Division,  ICST 
National  Bureau  of  Standards 
Washington,  D.C.  20234 

Walter  Kennevan  (IV) 
Director,  MIS  Program 
Room  206,  Hurst  Hall 
College  of  Public  Affairs 
American  University 
Washington,  D.C.  20016 

Kathleen  Kolos,  Recorder  (IV) 
CIA 

OS/ISSG 

Washington,  D.C.  20505 

Leonard  I.  Krauss,  Chairman  (IX) 
Manager,  Management  Consulting 

Service 
Ernst  &  Ernst 
140  Broadway 

New  York,  New  York  10005 

Milton  Lieberman,  (X) 
Group  Manager 

Merri  11 ,  Lynch ,  Pierce,  Fenner  & 

Smith,  Inc. 
165  Broadway 

New  York,  New  York  10006 

Fred  L.  Lilly  (III) 
Lilly  &  Harris,  CPA 
1113  Williamson  Building 
Cleveland,  Ohio  44114 

Theodore  A.  Linden,  Recorder  (VIII) 
Systems  Architecture  Section 
Systems  &  Software  Division,  ICST 
National  Bureau  of  Standards 
Washington,  D.C.  20234 

Thomas  C.  Lowe,  Coordinator 
Chief,  Systems  Architecture 
Section 

Systems  &  Software  Division,  ICST 
National  Bureau  of  Standards 
Washington,  D.  C.  20234 
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Don  C.  Lundberg  (VIII) 

IBM  Corporation 

1501  California  Avenue 

Palo  Alto,  California  94304 

Aileen  MacGahan  (IX) 
Assistant  Treasurer 
Chase  Manhattan  Bank 
1  Chase  Plaza  -  21st  Floor 
New  York,  New  York  10015 

W.  Gregory  McCormack  II  (VII) 
Senior  Electronic  Systems  Auditor 
Western-Southern  Life 
400  Broadway 
Cincinnati ,  Ohio  45202 

Herman  McDaniel  (IV) 
Director,  ADP  User  Education 
The  ADP  Management  Training  Center 
U.  S.  Civil  Service  Commission 
Washington,  D.C.  20415 

Robert  G.  McKenzie,  General  Chairman 

(Co-editor) 
Audit  Manager,  Logistics  & 

Communications  Division 
U.  S.  General  Accounting  Office 
441  G  Street,  N.  W. ,  Room  5814 
Washington,  D.C.  20548 

Philip  M.  McLellan  (XI) 
Manager,  EDP  Security  Branch 
Royal  Canadian  Mounted  Police 
720  Belfast  Road 
Ottawa,  KIA  0R2 
Canada 

Wallace  R.  McPherson,  Jr.,  Recorder 
(V) 

Director,  HEW  ADP  Standards  & 

Security  Programs 
HEW  OMT  (Room  551  D)^ 
200  Independence  Avenue,  S.W. 
Washington,  D.C.  20201 

Gerald  E.  Meyers  (III) 

Manager,  Internal  Audit  &  President 

EDP  Auditors  Association 

CNA  Insurance 

333  South  Wabash 

Chicago,  Illinois  60604 


James  F.  Morgan  (VI) 
GE  Information  Service 
401  N.  Washington  Street 
Rockville,  Maryland  20850 

Robert  Morris  (X) 

AT&T  (Room  5457B2) 

295  North  Maple  Avenue 

Basking  Ridge,  New  Jersey  07920 

William  Hugh  Murray,  Chairman  (VII) 

Senior  Market  Support  Administrator 

IBM  Corporation 

1133  Westchester  Avenue 

White  Plains,  New  York  10604 

Eldred  Nelson  (VII) 
TRW  Systems  Group 
1  Space  Park 

Redondo  Beach,  California  90278 

Albrecht  Neumann,  Recorder  (XI) 
Computer  Science  Section 
Systems  &  Software  Division,  ICST 
National  Bureau  of  Standards 
Washington,  D.C.  20234 

Hubert  S.  Obstgarten  (IX) 

Manager 

Ernst  &  Ernst 

1300  Union  Commerce  Building 
Cleveland,  Ohio  44115 

Kenneth  T.  Orr  (VII) 
Vice  President 

Langston,  Kitch  &  Associates 

715  East  8th 

Topeka,  Kansas  66607 

John  Panagacos,  Coordinator 
Manager,  Data  Base  Protection 
Equitable  Life 
1285  Avenue  of  the  Americas 
New  York,  New  York  10019 

William  E.  Perry,  Chairman  (III) 
Director  of  EDP  and  Research 
The  Institute  of  Internal 

Auditors,  Inc. 
International  Headquarters 
Altamonte  Springs,  Florida  32701 


Harold  J.  Podell  (VIII) 
Audit  Manager 

Logistics  and  Communications 
Division 

U.  S.  General  Accounting  Office 
441  G  Street,  N.W. ,  Room  5814 
Washington,  D.C.  20548 

Kenneth  A.  Pollock  (III) 
Assistant  Director  for  ADR 
Financial  &  General  Management 

Studies  Division 
U.  S.  General  Accounting  Office 
441  G  Street,  N.W.,  Room  6011 
Washington,  D.C.  20548 

Gerald  J.  Popek  (VI) 

University  of  California-LA 

3532  Boelter  Hall 

405  Hildgard  Avenue 

Los  Angeles,  California  90024 

Susan  K.  Reed,  Recorder  (VII) 
Systems  Architecture  Section 
Systems  &  Software  Division,  ICST 
National  Bureau  of  Standards 
Washington,  D.C.  20234 

Harry  Robinson  (XI) 

Vice  President 

Metropolitan  Life 

One  Madison  Avenue 

New  York,  New  York  10010 

Robert  S.  Roussey  (XII) 
Partner 

Arthur  Andersen  &  Company 
1345  Avenue  of  the  Americas 
New  York,  New  York  10019 

Zella  G.  Ruthberg,  General  Vice 

Chairman  (Co-editor) 
Systems  Architecture  Section 
Systems  &  Software  Division,  ICST 
National  Bureau  of  Standards 
Washington,  D.C.  20234 


Frank  S.  Sato  (III) 

Deputy  Assistant  Secretary  of 

Defense  (Audit)  and  Director, 

Defense  Audit  Service 
Lynn  Building,  Suite  607 
nil  North  19th  Street 
Arlington,  Virginia  22209 

Donald  L.  Scantlebury  (III) 
Director,  Financial  &  General 
Management  Studies  Division 
and  President,  Association  of 
Government  Accountants 
U.  S.  General  Accounting  Office 
441  G  Street,  N.W.  ,  Room  6001 
Washington,  D.C.  20548 

Barry  S.  Silverman  (IX) 
Manager  of  Internal  Audit,  EDP 
Gulf  &  Western  Industries,  Inc. 
1  Gulf  &  Western  Plaza 
New  York,  New  York  10023 

C.  0.  Smith,  Chairman  (IV) 
Assistant  Director,  Logistics 
and  Communications  Division 
U.  S.  General  Accounting  Office 
441  G  Street,  N.W.  ,  Room  5814 
Washington,  D.C.  20548 

Michael  J.  Sopko  (XI) 
GTE  Service  Corporation 
1  Stamford  Forum 
Stamford,  Connecticut  06904 

Carl  Spencer  (VIII) 

Glendale  Federal  Savings  &  Loan 

Association 
401  N.  Brand  Blvd. 
Glendale,  California  91209 

Fred  A.  Stahl 
Assistant  Professor 
Electrical  Engineering  and 

Computer  Science 
Columbia  University 
1312  Mudd  Building 
New  York,  New  York  10027 
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Norman  Statland  (XI) 
Partner 

Price  Waterhouse  &  Company 
1251  Avenue  of  the  Anericas 
New  York,  New  York  10020 

T.  Q.  Stevenson,  Recorder  (III) 
U.  S.  Department  of  Agriculture 
Room  4141-S 

Washington,  D.C.  20250 

Robert  Stone  (XI) 
Uni royal  Corporation 
Oxford  Management  and  Research 
Center 

Middlebury,  Connecticut  06749 

Ken  Sussman  (X) 

Supervisor 

Bell  Laboratories 

Holmdel ,  New  Jersey  07733 

Stephen  T.  Walker  (VI) 

Program  Manager 

Defense  Advanced  Research 

Projects  Agency 
1400  Wilson  Boulevard 
Arlington,  Virginia  22209 

Joseph  J.  Wasserman  (XII) 
J.  J.  Wasserman  &  Company 
11  Rock  Spring  Avenue 
West  Orange,  New  Jersey  07052 

Douglas  Webb  (VIII) 

EDP  Audit  Controls 

7700  Edgewater  Drive,  Suite  325 

Oakland,  California  94621 

Richard  D.  Webb,  Chairman  (XI) 

louche  Ross  &  Company 

1633  Broadway 

New  York,  New  York  10019 

Clark  Weissman,  Chairman  (VIII) 
System  Development  Corporation 
2500  Colorado  Avenue 
Santa  Monica,  California  90406 


Barry  Wilkins  (VII) 

Manager,  Audit  DP  Systems  and 

Servi  ces 
IBM  Corporation 
1000  Westchester  Avenue 
Harrison,  New  York  10604 

(ADS)Hart  J.  Will,  Chairman  (XII) 
Faculty  of  Commerce 
University  of  British  Columbia 
2075  Wesbrook  Place 
Vancouver,  British  Columbia 

V6T  1W5 
Canada 

Ronald  L.  Winkler  (VI) 
Associate  Attorney 
Sutherland,  Asbill  &  Brennan 
1666  K  Street,  N.W. 
Washington,  D.C.  20006 

Donald  R.  Wood  (XII) 
Partner 

louche  Ross  &  Company 
111  East  Wacker  Drive 
Chicago,  Illinois  60045 
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APPENDIX  B: 


EVOLUTION  OF  THE  WORKSHOP  AND  PROCEEDINGS 


1 . 


INITIATING  THE  WORKSHOP 


The  National  Bureau  of  Standards  initiated  Task  Group  15  (TG-15) 
within  the  Federal  Information  Processing  Standards  (FIPS)  program  in 
1973  to  develop  standards  in  Computer  Systems  Security.     TG-15,  chaired 
by  Dennis  K.  Branstad  of  NBS,  was  composed  of  representatives  from 
private  industry  as  well  as  Federal,  State  and  local  governments.  In 
March  of  1975  an  informal  task  team  on  Guidelines  for  Computer  Security 
Auditing  was  formed  within  TG-15.     It  was  chaired  by  Robert  G.  McKenzie 
of  the  General  Accounting  Office  and  had  Zella  G.  Ruthberg  as  the  NBS 
liaison  person.  Its  mission  was  to  be  two-fold:     1)  to  convene  a 
workshop  on  security  auditing  that  would  consolidate  the  state-of-the- 
art  information  available  in  the  field  and  define  areas  for  future 
research  and    2)  to  adapt  this  information  to  the  needs  of  Federal  agen- 
cies in  the  form  of  Federal  Information  Processing  Guidelines.     The  In- 
vitational Workshop  on  Audit  and  Evaluation  of  Computer  Security,  which 
took  place  on  March  22-24,1977  in  Miami  Beach,  Florida,  accomplished  the 
first  of  these  two  tasks.     Since  TG-15  was  terminated  as  a  formal  com- 
mittee in  the  Spring  of  this  year,  the  second  task  is  expected  to  be  ac- 
complished by  a  working  group  convened  for  this  purpose  and  will  result 
in  a  FIPS  Guideline  publication  by  the  National  Bureau  of  Standards. 


Under  Robert  McKenzie 's  direction  and  Zella  Ruthberg 's  assistance, 
the  TG-15  task  team  worked  on  developing  what  was  hoped  would  be  a  pro- 
ductive format  and  a  comprehensive  set  of  topics  for  the  workshop.  It 
was  an  informal  group  consisting  of  Peter  S.  Browne  of  Computer  Resource 
Controls,  Adolph  Cecula  of  the  U.S.  Geological  Survey,  Robert  H.  Court- 
ney of  IBM,  Frank  Drefs  of  HEW,  Robert  V.  Jacobson  of  Chemical  Bank, 
John  Panagocos  of  Equitable  Life,  and  Harry  Robinson  of  Metropolitan 
Life..     Inputs  on  possible  topics  were  contributed  by  the  task  team 
members  as  well  as  requested  and  received  from  William  E.  Perry  of  the 
Institute  of  Internal  Auditors,  Robert  L.  Stone  of  the  American  Insti- 
tute of  Certified  Public  Accountants,  and  Keith  Dorricott  of  the  Canadi- 
an Institute  of  Chartered  Accountants. 


2. 


PLANNING  THE  WORKSHOP 
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2.1    Workshop  Format 

The  format  decided  upon  was  a  relatively  small  invitational  topic- 
area  workshop  that  would  cover  ten  major  areas  of  concern  in  computer 
security  audit.     Each  topic  would  be  handled  by  an  interdisciplinary 
group  of  not  more  than  ten  individuals.     It  would  be  chaired  by  a  recog- 
nized authority  in  that  area  and  staffed  with  a  broad  range  of  experts 
mainly  selected  by  its  chairman.     A  concerted  effort  would  be  made  to 
obtain  representation  from  both  the  audit  and  computer  communities.  The 
job  of  Recorder  for  the  various  sessions  was  assigned  to  task  team 
members  and  NBS  people.    During  the  Workshop  the  Recorders  were  respon- 
sible for  capturing  and  distributing  in  printed  form  major  ideas 
developed  in  their  sessions.     Some  Recorders,  by  mutual  agreement,  did 
much  more  than  that.     A  few  task  team  members  were  to  be  session  coordi- 
nators as  well  as  provide  a  pool  of  back-up  attendees  for  las't  minute 
drop-outs.     Robert  McKenzie  was  to  be  the  General  Chairman  and  Zella 
Ruthberg  the  General  Vice  Chairman.     This  last  arrangement  provided  the 
vehicle  for  the  excellent  support  given  this  workshop  by  both  GAO  and 
NBS. 

Each  session  was  to  spend  over  two  days  developing  a  position  paper 
on  their  topic.     If  no  consensus  could  be  reached  a  majority  and  minori- 
ty report  was  requested.     The  last  afternoon  was  set  aside  for  the 
presentation  of  conclusions  by  the  chairman  of  each  session.  The 
results  of  these  discussions  would  be  published  by  NBS  in  a  Proceedings. 
It  should  be  noted  that  this  format  was  patterned  after  the  highly  suc- 
cessful NBS  Workshop  on  Data  Base  Directions  held  in  October  of  1975. 


2.2    Workshop  Topics  and  Chairmen 

It  was  recognizee  that  no  set  of  topics  could  be  selected  to  cover 
the  main  areas  of  the  subject  and  also  be  mutually  exclusive.  There 
would  be  unavoidable  overlapping  with  any  set  of  topics.     The  actual  to- 
pic selections  by  the  task  team  were  ultimately  made  from  the  point  of 
view  of  covering  the  major  considerations  in  any  computer  security  au- 
dit. 

The  topic  areas  and  the  selected  chairmen  were  as  follows: 

INTERNAL  AUDIT  STANDARDS  William  E.  Perry 

Institute  of  Internal  Auditors 

QUALIFICATIONS  AND  TRAINING  C.  0.  Smith 

U.  S.  General  Accounting  Office 

SECURITY  ADMINISTRATION  Blake  Greenlee 

Citibank 

AUDIT  CONSIDERATIONS  IN  VARIOUS 

SYSTEM  ENVIRONMENTS  Carl  Hammer 

Univac 

ADMINISTRATIVE  AND  PHYSICAL 
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CONTROLS  W.  H.  Murray 

IBM 

PROGRAM  INTEGRITY  Clark  Weissman 

System  Development  Corporation 
DATA  INTEGRITY  ....Leonard  I.  Krauss 

Ernst  &  Ernst 
COMMUNICATIONS  Jerry  FitzGerald 

Stanford  Research  Institute 

POST-PROCESSING  AUDIT  TOOLS 

AND  TECHNIQUES  Richard  D.  Webb 

Touche  Ross  &  Co. 

INTERACTIVE  AUDIT  TOOLS  AND 

TECHNIQUES  Hart  J.  Will 

University  of  British  Columbia 


2.3    Pre-Workshop  Session  Activities 

Each  chairman,  with  guidance  from  the  General  Chairman  and  Vice- 
Chairman,  then  proceeded  to  fill  his  session  with  a  balance  of  individu- 
als from  the  audit  and  computer  communities.     A  more  elaborate  descrip- 
tion was  written  for  each  of  the  session  topics  and  distributed  to  all 
prospective  participants  to  enable  them  to  come  to  the  workshop  with  a 
clearer  idea  of  the  subject  of  their  session.     Session  chairmen  were 
asked  to  request  and  distribute  pre-workshop  position  statements  from 
their  participants  in  order  to  stimulate  their  group  to  formulate  some 
of  their  ideas  prior  to  the  workshop.    Many  participants  prepared  such 
pre-workshop  statements  so  that  in  general  the  convened  sessions  were 
able  to  progress  very  rapidly.     Each  session  chairman  was  given  complete 
freedom  to  structure  his  session  in  any  way  he  felt  might  be  productive. 
This  proved  to  be  a  useful  tactic  since  it  gave  each  chairman  and  his 
attendees  the  latitude  of  being  able  to  operate  in  a  manner  they  were 
most  comfortable  with. 


3.     AT  THE  WORKSHOP 


After  the  keynote  address  had  set  the  stage  for  the  activities  of 
this  Workshop,  the  individual  sessions  each  met  separately  for  two  and 
one  half  days  to  develop  their  thoughts  on  each  of  their  topics.  Each 
session  had  a  Chairman,  a  Recorder,  and  four  to  eight  attendees.  They 
were  supplied  with  a  folder  for  each,  containing  a  copy  of  FIPS  PUB  39 
("A  Glossary  of  Terminology  for  Computer  Systems  Security"),  the  Canadi- 
an Treasury  Board  Guide  on  EDP  Administration  entitled  "Security  in  an 
EDP  Environment,"  plus  various  writing  materials  to  make  things  con- 
venient.    The  Workshop  office  at  the  meeting  site  supplied  the  sessions 
with  continuous  typing  and  xerox  services  to  expedite  matters.     On  the 
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last  afternoon  of  this  three-day  effort  the  attendees  again  met  as  a 
single  group  and  each  session  reported  its  findings.     At  the  end  of  the 
Workshop  eight  of  the  sessions  submitted  a  rough  draft  of  their  report 
and  two  submitted  detailed  outlines. 


4.     THE  SESSION  REPORTS 


The  session  attendees  were  given  a  great  deal  of  latitude  in  pro- 
ducing their  session  reports  with  the  result  that  no  two  reports  were 
produced  in  exactly  the  same  way.     In  some  cases  the  writing  of  the  re- 
port was  divided  among  all  the  attendees  at  that  session.     In  other 
cases  an  individual  or  a  small  group  from  the  session  wrote  the  report. 
In  most  cases  the  written  report  was  reviewed  by  all  the  members  of  the 
session.     Although  the  attendees  of  each  session  were  given  the  option 
of  producing  a  majority  and  minority  report,  all  groups  produced  only 
consensus  reports. 

In  presenting  the  reports  in  these  Proceedings,  the  editors  intro- 
duced an  Editors'  Note  at  the  beginning  of  each  report.     This  contains  a 
brief  biography  of  the  session  Chairman  and  a  statement  of  the  complete 
charge  given  to  that  session.  Included  at  the  end  of  this  Editors'  Note 
is  a  brief  statement  concerning  the  manner  in  which  that  report  was  pro- 
duced . 
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